Notes From a Tool User - An Agile Blog

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 the 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 the 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 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

in Toronto

June 1-2, 2015

Comments

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.)

http://leanthinkingyoursoftware.blogspot.com John Goodsen

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.

Mark Levison

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.

http://www.nexj.com Patrick Li

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?

http://www.VersionOne.com MH Lines

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

http://www.rinivansolingen.nl @solingen

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.

http://www.jbrains.ca/training/product-sashimi J. B. Rainsberger

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.

madhan

@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?

Mark Levison

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 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.

Mark Levison

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

http://twitter.com/CuriousAgilist Bob Allen

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.

http://agilepainrelief.com/notesfromatooluser/ Mark Levison

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.

Maury Richards

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.

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.

Pratik

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.

http://agilepainrelief.com/notesfromatooluser/ Mark Levison

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.

5 Steps for Creating High-Performance Teams FREE

Get a FREE e-book copy of Five Steps Towards Creating High-Performance Teams and put your team on the path to high-performance success.Sign up & download instantly!