A question that comes up again and again from teams is “What is the right size for a User Story?” – a day? a week? three weeks? – 1 point? 5 points? 10 points? 37? 100? 5 words? 20 words?
Short answer: there isn’t a universal right size for a User Story, it depends on your team, their skills and their level of domain knowledge.
Long answer: for some teams a User Story is Big, several days or weeks of work. On other teams they are small – maybe a day’s work. Both are possible, both are the right answer. Although, as a general rule smaller is better.
For me there are criteria that a User Story should meet:
- It should be small enough for the technical team to understand it and create in in a short time period
- It is small enough to move on the board sometime soon
- It should be big enough to represent business value in its own right – it might build on something that has been done before (e.g. a lower fidelity version of the same story, the new one increasing fidelity)
- It is big enough to be deliverable in its own right – you might not want to do so but if you needed to you could
When a team are dedicated to a particular product, and have worked on it for several years, and have learned about the domain – as I would expect in for in-house development operations – I expect to see larger stories. Conversely, when a team don’t know the domain – as is common with outsourced development – I expect to see small stories, and more knowledge pull from the client.
Taking a step back, a few basics:
- A User Story is not in and of itself a requirement; I like to call them “Tokens for Work to be Done”, others like to say they are “A placeholder for a conversation” both are true
- Don’t feel that you must use User Stories: if the format doesn’t fit your need then don’t use it! You can still have a “token for work to be done” and a “placeholder for a conversation” using any words you like, they don’t have to be “As a… I can … So that…”
- The User Story format does capture three very important elements: Who, What, Why so they make a good starting point and are easy to understand but if they don’t work for a particular need then don’t force it into the format
One common problem I see is teams who create really small stories in order to get them to fit within one sprint. These means large stories don’t get scheduled or teams split large stories into many small ones which have no business value themselves.
People say this is a Scrum thing, I’m not sure. Scrum doesn’t mandate User Stories, the story format came along after Scrum. True the format is widely used they has become part of Common Scrum.
What Hard Core Scrum does say is that all the work the team commit to should be done by the end of the Sprint. Which would imply a story has to be small enough to fit I the Sprint. The problem then comes: what else do you put in the Sprint? If one story is going to take more than half the Sprint you need one or more stories to use the rest of it up. Plus you hit the commitment problem – developers have an incentive to under commit and the business/custom has an incentive to over demand.
My solution – one which I’m baking into my description of Xanpan – is:
- Stories are split into Tasks during the planning meeting
- Tasks do not follow any particular format, nor do tasks have any business value
- Tasks are for the team – the developers, testers, analysts and anyone else
- Tasks should be small, a day or two at most.
- A story is not done until all the tasks are done. Stories can therefore flow across iterations, the chances of tasks flowing across iterations is low (because they are small) but they can and do.
As I’ve written before, the breakdown of stories to tasks fills (at least) three purposes:
- It is superficially an estimation exercise
- It is also a requirements elicitation process (I like the Requirements Engineer, BA, Product Owner/Manager to be present)
- It is a design activity.
So there you have it: there is no right size of a User Story.
That said, they may still be “too big” or “too small”. But what constitutes right it dependent on you, your team and how you play the game.
I just found this on dzone and well… some stuff never really grows old. 😉
“But there comes a point were stories become too small to return any business value at which point they, well, loose value.”
Exactly! Too often I ran into “Well, but what’s the core!?” situations, were at the end always was just one answer left: “If you want to put it the hard way: there’s none.” I know how often processes get queezed between dev and marketing, just to be feature creeped by sales – BUT: if it doesn’t have any value that you could actually sell, even a minimum value… there’s no purpose in it at all. And tbh: Often customers don’t really value a too small user story/product that fits their needs, but not their imaginations.
I also disagree about the velocity calculation. Getting credit for delivery of tasks ignores the fact that the story is more than the sum of its parts. If the nature of the work requires stories that are so large they can't be delivered in a sprint (and this is a big "if"), then I think the team should consider lengthening its sprints. There is also the whole topic of infrastructure and architecture stories, which by their nature may have no "business value" as defined by the sales department. But the architecture group (you do have one, don't you?) may disagree. So it's not that simple.
In replying to those comments I just had course to check one of the Scrum reference books and was reminded that strict Scrum – as defined by Schwaber and Sutherland – doesn't have anything to say about User Stories.
Instead Scrum talks about "Product Backlog Items" – which some call PBIs. In my experience the most common form a PBI takes is a User Story.
So in general, as far as I am concerned:
* A Product Backlog Item is a User Story, or possibly a Task
* A User Story is a Minimally Marketable Feature (MMF)
* MMF is synonymous with Quantum of Value (QoV) and Business Value Increment (BVI)
Any more terms I've missed out?
Jon,
Probably I should have written "only completed tasks are counted" i.e. for the purposes of velocity only tasks which have moved across the board to some form of Done are counted. Some teams have a column for tasks to regroup as stories, other just manage it ad hoc – sounds like a problem but usually isn't.
As to 90% done I it depend on what you are looking for. In terms of the product stories are done or not done but for a development team looking for an indication of how much work they have left then 90% of the effort expected might be useful. That said, I agree its not reliable. But, I find this approach better than the approach of some teams who estimate Stories in "Story Points" and tasks in hours. I've even seen burn-down charts and tracking spreadsheets that ask developers to switch to hours for the last leg.
As to Waterfall I don't really care: there are no prizes for being perfect Agile and if sequencing some work helps then do it.
And shipping product: if stories are regularly spanning sprints then I expect some stories to be completed every sprint and some to carry over. Thus you will have a releasable product of the stories that were completed.
I would watch how long it takes stories to complete, and I would watch how much work spills over: I want to minimise both and will work towards that end. However I think the argument that "this is how it in in Scrum" is too simplistic.
Hi Allan,
you write "only completed tasks are done". Suppose I have 5 Stories and these are all split up into 10 tasks each. Later on 9 out of each of the 10 tasks for each Story is done. So 45 out of 50 tasks are done. So you are 90% done. The problem is you have not completed _any_ Stories. You are quite likely to be drifting to Waterfall – where you are always 90% done but nothing ever gets shipped. Isn't one of the key messages of Scrum that only Stories get Done?
I'm broadly in agreement, until you talk about calculating velocity for tasks delivered.
I'm not a huge fan of velocity calculations in the first place, but if they are going to be used then only stories delivered (i.e. business value) should count.
You may get the occasional mega-story that won't fit into a sprint and genuinely can't be broken down. This should be sufficiently rare that any transient impact this has on velocity is accepted.
Seb,
I want to agree with you (and Duarte) about velocity calculation but I've seen cases were they work. I'm still working it out in my own mind.
So far my conclusion is: Velocity is useful in the small, for allowing the team to judge how much work to accept sprint-to-sprint and for short term approximate planning.
But at scale, over months and even years velocity and points break down.
What I didn't examine in the post is the maturity of the team and the requirements people. My belief is that when the team are mature then mega-stories as you describe really are the exception. But when the team and requirements people are new to the process then I expect sprint spanning stories to be more common.