When Agile/Scrum Trainers teach about new teams about User Stories, we usually talk about Bill Wake’s INVEST criteria, which includes Small:
Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.
This statement is a great start, but it doesn’t explain why or give you much guidance about what to do.
Why Small Stories?
Why not just give the team large stories that span iterations. Why are always asking if you can slice those stories smaller? A number of reasons:
- Small stories provide focus and a short horizon for the team. It’s easier to get lost in the details with a larger story.
- When you still have development to test handoffs (i.e. before you start doing ATDD (Acceptance Test Driven Development), smaller stories enable more frequent handoffs and allow testers to work on smaller chunks of code.
- Small stories give you the flexibility to reconfigure and adapt to new discoveries or changes. Perhaps the PO discovers that an existing story is now irrelevant; or while coding you discover a surprise. Small stories make it easier to adapt.
- Small stories provide more feedback opportunities at all levels of the system and more opportunities for personal satisfaction; think of the small dopamine rush that happens every time you complete something!
- Large stories increase the risk that your team will deliver nothing at the end of the iteration.
- Your team has a capacity like a drain pipe and just like a pipe the larger the object you try to push through it the more likely it is that blockages and bottlenecks will occur. Perhaps one person who is tied up in the large story may also be the only person who can complete a key piece of another story.
So what is my guidance for new Scrum teams when they’re trying to decide on Story size? Two people for half an iteration. Why two people? Because most stories require collaborative effort and I want to encourage pairing/collaboration. Why half an iteration? Because any larger makes it quite likely that the story will not be completed in a sprint. Even stories of this size are still a bit large, and they shouldn’t commit to more than one of these per sprint. For some strange reason with most teams I coach, stories of this size are 13 Story Points, I don’t really know why this happens.
All this suggests that most stories are going to be in the range of 1-5 story points by the time the team is ready to commit to them. You can still have Epics and Themes they should just be split into much smaller parts before the team attempts to commit to them.
But That’s Really Small
If we’re working in bite size chunks, how do we get any meaningful work done? How do you slice them so small? Part of the problem is a frequent misunderstanding around value in stories. The ‘V’ in INVEST stands for valuable, many people assume that equates to business value or a feature that you can sell for a dollar. When we combine user stories together, they represent features that customers will pay for. But on their own they’re too small for that. Instead value refers to the point of view of the user for whom the story was written in the first place.
So the hard part how do you slice? Some simple ideas:
- CRUD (Create, Read, Update, Delete) boundaries
- Acceptance criteria – often the acceptance criteria on the back of the Story Card will give a good hint.
- Happy Path – many stories have exceptional conditions, consider splitting them out
- Simple versions of an algorithm. With a complex algorithm and complex UI, it might be worthwhile to do a simple version of either first and then fill in the detail in the next story. Sometime this can come from making some elements constants instead of looking them up or calculating them
Bill Wake: Splitting Stories, Rachel Davies: Ideas for Slicing Stories and Lasse Koskela: Ways to Split Stories have much longer lists.
What not to do: Split along architectural or technology boundaries, as this will create stories that don’t deliver value to an end user.
When slicing stories imagine using a scalpel and not a butcher’s knife. Go create some story sashimi.
Update: I was asked for some examples and I’ve written some in More Story Splitting.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
Beautiful metaphor — “a scapel and not a butcher’s knife.”
I think the key is leading with “why” … “why” do we even use stories?
Stories help us bridge with the customer, know what good looks like, and estimate our work. So pairing stories down is fine, and a good thing, as long as we can still achieve those basic goals.
Stepping back, one confusion I always see is the “user story” vs. the “developer story.” (where the user story is split into developer tasks.)
I think there are actually two other problems folks run into but don’t realize it:
1. cuttable scope (having stories that make it easy to cut scope or deliver incremental value and translate to something stakeholders can underestand.)
2. keeping bigger stories and litter stories organized. This is actually a solved problem, but you have to borrow from “scenario trees” or “utility trees” (and I’ve found Mind Maps to be the best vehicle.)
Worrying about splitting stories to fit into arbitrary iterations is wasteful. Teams should understand and focus on delivering business value and not breaking work into arbitrary time-boxes. Sure, keep it small, but if you have a big feature that is hard to decompose, then just build it and move on rather than play games about splitting stories and pretending they still have business value. This is why Kanban with XP practices is growing as an alternative to Scrum.
John – I’m bewildered. If don’t like Scrum and prefer Kanban that’s fine. However I don’t see the linkages between Scrum and User Stories. There isn’t one, in fact User Stories come from the XP world of all strange places. Quite aside from fitting stories into an iteration there are number of principles that underlie the reasons I listed in the article. If nothing else consider the batch size problem. The larger the size of the items in the queue the longer it takes to get them all complete. You might also consider the visibility problem with a large feature. How do we really measure progress and where things stand. Honestly large features smack of the waterfall world that we’ve only just abandoned.
Confused.
Hi Mark, I read this story and have a question. I am on the product side of the house. Have been doing product management for about 20 years. My organization has put a “rule” in place – not a suggestion or recommendation or a “most situations, with exceptions” – but an actual rule that no story can exceed 5 points. While I completely agree with all the thoughts in your article about keeps stories small, if work cannot be broken down into a testable unit, breaking a story into two (just so you can say the stories don’t exceed 5 points) creates work and seems absurd to me! Now, if Dev or QA comes up with a problem with our requirements, I sometimes have to update 2, 3 or more tickets (all of which have identical requirements).
Have you seen this before? Why would anyone do this? Is there any value in literally “cloning” stories to keep them within the 5 point maximum?
Curtis – for some reason this comment missed my inbox. Sorry. I’m very uncomfortable with hard and fast rules. Clearly I prefer small stories that still deliver value. However playing artificial games to play inside a rule seems the opposite of Agility. If the problem happens rarely I would just deal with a larger story. If it happens frequently then I think the PO and Team need to work on Story Slicing and Defining Value as a skill. (In case it isn’t clear – cloning stories seems to madness, as is Dev and Test stories).
FWIW if the team is really struggling dig into Ensemble/Mob Programming: https://agilepainrelief.com/glossary/mob-programming to get the whole team focused on value.
Mark,
Nice article. The point about slicing vertically is especially helpful. The difficulties I have encountered so far are breaking down technical features in the back end. It could be a service or integration engine. There is no person user for this feature or at least they are several layers removed. How would you word such a story and slicing that down into a few man day sizes from man month sizes?
We split our stories as small as possible, always striving for a one or two, but I’ve found that it can wind up killing a bit of strategy – let me give you a good example. I produce an agile Webinar series every two weeks. I break the stories into the pieces of shippable content (in this case, individual web pages and emails that go live).
I manage my priorities by focusing only on what is next on my tasks or stories for the iteration. In doing that, the emails, which are very similar, can be separated by a few pieces of work. When I get back to the webinar work, I’m almost starting from scratch, when in reality, it is similar work. A larger story, with all similar pieces, would actually wind up saving time.
It is a constant debate on our team, probably one based on personal preference.
@Mark – excellent article! I can vouch from real-world experience that all of your ideas work!
@John wrote: “Worrying about splitting stories to fit into arbitrary iterations is wasteful. … This is why Kanban with XP practices is growing as an alternative to Scrum.”
There may be many good reasons why “Kanban with XP practices” is gaining momentum over Scrum. However, the idea that splitting stories is wasteful isn’t one of them. Kanban works best when all stories of are of similar size. This concept falls apart when you have some very large stories mixed with mostly small, more manageable stories.
You absolutely have to pare down those larger stories into more manageable chunks, if for no other reason than to get a good rhythm going as you knock off your queue of Kanban stories. One basic reason for this is that with Kanban, story size is ignored – each story is assumed to be of similar size. The focus then turns to the elapsed time between the start and end of the story – and getting it done asap before moving on to the next story. This is what gives you your Cumulative Flow Diagram. You just can’t do that as effectively with stories that are “too large” to get done in a couple days or a couple weeks. Fluctuations end up depending on the mix of large and small stories – which might be misleading. You can separate stories into different streams, to produce CFDs with different “levels of service”, but just because the team is too lazy to split the stories into better, smaller units is insufficient reason to say that they’re different “levels of service”.
As Mark mentioned, the idea of small story sizes comes from XP – not from Scrum or Kanban. It’s just as important to have small stories in a Kanban/XP framework as it is in a Scrum/XP framework. Small stories give the team a self-satisfying pace/rhythm, whereas stories that are too large are a pain in the ass.
With Scrum OR with Kanban, the time it takes to right-size each story is well worth it – the time spent is more than gained later by avoiding the issues that you almost always encounter with stories that are “too big”.
Kirk Bryde, CSM, CSP, PMP
Good clarification! I like the 2 people half sprint, rule of thumb. That seems both sufficiently small and large.
Sometimes user-stories can, however, also be too small. The rule of thumb I use for that is: when a user-story seems sufficiently clear by itself to start developing the software directly, then it is propably too small! After all, a user-story is: an invitation to a conversation.
When user-stories can be used as documented requirements (they do not require any form of interaction anymore) they seem too small.
In Product Sashimi, we teach splitting feature areas (often epics) into examples (scenarios), then bundling those examples as needed into features (stories). I prefer this, because it focuses on finding the kernel of a feature idea, which we could implement first, before figuring out all the stories and worrying about how big they are.
I have found so far that people feel very uncomfortable deferring details about some important examples simply because they don’t form part of the kernel of the feature area. I need to learn more about how to help them feel comfortable.
@Mark – nice article.
But, I am still not able to grasp the concept of “Two people for half an iteration”. Can you please explain in detail?
Madhan – thanks for taking the time to comment. “Two people for half an iteration” is a rough measure of the maximum story size:
Two people implies that getting a story to “Done” always requires at least two people working together.
Half an iteration – any story that is longer than half an iteration will be a bottleneck and is unlikely to be completed by the end of the sprint
If you want to see what happens when a team doesn’t split their stories to relatively small size, see: ScrumMaster Tales The Story of an Incomplete Sprint
Thanks for the clarification Mark.
We use a pretty aggressive measure – one-day stories.
If the team can’t get the story done in a day, it’s too big. Then we ask why they can’t get it done in a day. The answer(s) are the impediment list. Knowing the impediments to a one-day story lets us either resolve the impediments and reduce the “cloudy” nature of the original story into more of a “box of one-day size” that we can then get moving on. Or – it identifies that some part of the original story can be split out to its own story (not really a dependency of the original).
After we start development, if the story isn’t done (meaning: TDD completed, all tests passing, code reviewed and approved) in a day, then we need a post-mortem on why actual didn’t match expected.
Bruce – I agree however most don’t get that far. This item was written in the context of teams that are struggling to justify splitting stories that are greater than 2 people, 2 weeks in length.
Cheers
Mark
Great post on an important topic, especially to the audience you’re aiming for. I have an anser that some may disagree with, but there’s some really good reasons for it. Riffing on Albert Einstein “Everything should be as simple as possible, and no simpler”: same for stories. This yields one very significant benefit: if it cannot get any simpler, it’s a sure bet that everyone understands it.
There’s a second benefit that works especially well with a controversial “estimating” practice: don’t estimate. During sprint planning teams don’t bother with estimating but instead evaluate each story, starting with the top of the rank-ordered-backlog (no skipping), and answering whether or not they feel confident that they can get the story done in the upcoming sprint. The usual conversations take place to explore any outliers, which usually exposes unknowns and/or misunderstandings. The process stops when the sprint is “full”, meaning as soon as the team cannot agree that they can confidently deliver the story in question.
This non-estimating approach not only saves time and stress, but also cannot be gamed. If a manager is tracking the number of widgets delivered each sprint, the predictable response from a team is to game the system by inflating the story point estimates. When whole stories are what’s being tracked instead, the only way to “game” the system is to have more (i.e. smaller) stories, which actually tends to be a good thing.
Bob – thanks for the comment. As I mentioned elsewhere in the thread – I like the model. The only thing is you have to be fairly consistent in just small you slice the stories, so that you can just count the number of stories to get a sense of how far off done is.
I like the idea of the simplest it can be. I do really like velocity though. As I tell my team all the time, story points aren’t for them. They should do sprint planning just the way you say. Story points are for the PO and SM when they are planning releases. They are for future estimating and I have found them to be invaluable when reporting back to the organization when we think we can get to what.
Mark,
Great blog post. I’d recommend you add Richard Lawrence’s new flow chart on story splitting:
https://www.richardlawrence.info/2012/01/27/new-story-splitting-resource/
As to the recommended story size, in my User Story Maturity Model, I suggest teams try to get to stories that are 5 days or less first, then try to get them down to 2-3 days. More on my maturity model here:
https://www.scrumcrazy.com/The+Bradley+User+Story+Maturity+Model
I tend to agree with your reference to half the iteration length, especially for 1 week iterations.
Nice write ups 🙂
I am a die hard blogger, a budding Agilist… I am a big fan of yours and my first blog on Agile was published on Scrum Alliance …
https://www.scrumalliance.org/articles/440-stumbling-blocks-
https://gpzee.wordpress.com/
Please review the same and respond with your feedback.
Br.
GP
Good article. What do you think of having more small user stories? when we are having more user stories for huge application do you think “User Story Hell” might happen? how to handle that situations?
@Srinu – what would happen if you simply limited your entire Product Backlog to 100 Items? Once you take 5-10 off the top you would just split the next most important batch.
End result – small, well understood stories before you work on them but no User Story hell. Not even heck 🙂
Small userstories, good idea. I like that, what I don’t like is that the planning and pokersessions are getting reaaaaaal long because of the slicing which has to be done in those sessions.
Wilko – Possibilities:
– You’re estimating too much at once.
– You’re splitting too soon
If you get really good at splitting then you don’t need to estimate the split stories, because they will all be within one std deviation of size 2.
Good article about an important and difficult topic. I would hypothesise that teams often don’t fully understand relative sizing so start with 1 man day = 1 story point. Two people for 5 days is 10 man days. As much estimation is done using Fibonacci, 13 is the only number it could be.
Pratik – thanks while I agree that many team members struggle to understand “2”. Turning it back to ideal days destroy’s the whole estimation process. Better for the team to agree on something small that they believe they could deliver 5-10 of in a Sprint.
Thanks for the insight. This is a problem we are faced with right now.
Yay – another team that will right size its stories 🙂