I attended a meeting today held by a team new to agile. They are essentially the business people at the start of a project and trying to break down their requirements. They were having a bit of trouble knowing when to break up stories, when to have more detail and when they’ve put in too much detail etc.
I found it very interesting. Firstly- I’ve never been involved at that stage of an agile project before. The distinction here being agile – I have helped break down requirements but not into stories, and usually I did everything with my ex-developer hat on and broke things into developer tasks. I have read the books/blogs/articles etc though and so I know what the end result “should” look like 🙂 The process is fascinating. And highlighted that I need to brush up on the topic – hence the blog post 🙂
As almost everything with agile, the lesson is not to over think anything. Keep it small and simple. If you feel you must add some detail – then do it. It should feel natural and easy. As with all new things, people are worried that they wont do “it” right and then some water treading/paralysis occurs. Think of Nike and “Just Do It”. Then retrospect, learn and go for it again. After all that is the agile process 🙂
It is a learning process and only when these stories get discussed with the team in sprint planning – will you be able to reflect and see where you can improve, simplify, be more explicit etc.
It is its own sprint. The team (in this case of business analyst, business architect and product owner) get together and work on a ‘area of work’. Their goal is to break that ‘area of work’ into smaller user stories that when given to the development team will communicate what needs to be delivered/demo’ed for the story to be considered done. This team works in excel – as it then translates into the backlog fairly quickly. That made me a bit sad for them. I think having a big visible, colourful board is awesome for a team. And their team doesn’t have one – no fun in that…
ok – brushing up (using good old Google…)
The standard definition of a user story:
As a type of user
I want some goal
so that some reason
Some tips I came across for writing good user stories:
- Make them customer-focused (as opposed to developer focused)
- Make them elevator-friendly (you should be able to explain this story in 30s to a team member)
- Make then the right size (they need to fit into a sprint, hopefully with a bunch more stories – practice and discussions with the team will improve this)
- Make them testable (give a precise pass test for the story, it should not be open to interpretation)
User stories are comprised of 3 aspects: a written description [card], conversations that flesh out detail [conversation], tests that determine when a story is complete [confirmation].
It seems that this team is also trying to incorporate a bit of BDD (Behaviour Driven Development). So each user story is being broken down into acceptance criteria in terms of scenarios, the definition being:
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.
Whilst I’ve heard of BDD I’ve never actually read up on it – guess I’ll add that to my list (that is growing at an alarming rate!).
Its been awesome to see how another part of agile works (as opposed to just the development team), and learning the how’s and why’s to their daily tasks, questions and frustrations – looking forward to more 🙂