Breaking Down User Stories
This post has been moved to my company blog at Growing Agile – you can read it here:
http://growingagile.co.za/2012/12/breaking-down-user-stories/
11 Comments
Post a comment
by Karen Greaves
All good advice. There is also the question of whether the architecture is too complex.
Great info here. Posted a VIA on our site! Thanks for the awesome work!
Cool! Thanks for the link
Hi Karen,
Fantastic article on User Stories.
The one thing I have been thinking about is a slight tweak to them based on the requirement of the Story.
“As a I want” implies that it is additional functionality.
Every system requires minimal functionality to exist, these need to be indicated.
So what I suggest with our teams is this critical stories are worded differently:
“As a I need” Implying that it has to exist,
These generally form part of the absolute highest priorities for a minimal viable release.
Keen to hear your thoughts
Hi Nick
I tend to think using need instead of want is a way of indicating priority. My preference is to have priority linked to each item in your backlog, but not necessarily in the wording of the story, because priority can change depending on business conditions. Rewriting stories every time business priorities change seems unnecessary to me.
Also try to think of the “As a … I want… so that” just as a template to make sure you are considering all the important parts i.e. the role, functionality and value of each story. Once you get used to this you can probably phrase it in better english without using the format as strictly.
Hi Karen,
Thanks for the great article.
Hi Karen
We tend to have issues around when to do architecture. Should we get all the user stories and then do a quick high level architecture for the system before going and doing story points or should we get the stories, do the story points and then do architecture only for what we are delivering? (I tend to feel its a good idea to have a kind of whole picture architecture before jumping in)
What do you advise?
I think it helps to have a high level idea of the architecture when you are discussing a story at the epic level. The key is the 80/20 rule. get 80% with 20% effort, i.e. don’t spend too much time on making it perfect, and maybe even have a few options for the architecture. As you flesh out the epic and add stories understand how those might fit into or change your architecture, this might also impact the order you do stories in. If something in the architecture is risky, you can influence the product owner to do a story that uses that part of the architecture first to find out if it works before you build everything.