In response to my recent Story Splitting post, I had a few questions and couple of confusions that need clearing up.
A few elements of the INVEST criteria need some discussion:
- Negotiable – the details are negotiated with the Product Owner as the team goes to implement the story. However that negotiation is a two street and not an excuse to ask for scope creep.
- Valuable – the story has to be valuable to a User however that may not be enough value to be worth releasing at this moment. Instead it may take several stories together to be sufficient value for the end user. For example if we imagine the login page for a new site that needs to support its own signup system, Facebook, Twitter and OpenID. It may not be worth releasing the page without all the elements yet they still maybe good places to make a split.
- Small – Bill’s original definition says small. I prefer ‘Sized Appropriately’. So things that are to be developed in the near term (perhaps 4-6 sprints) should be broken down into Stories and Estimated. Things that are further out should remain as EPICS.
Should we Slice at all? One person has suggested that if a story doesn’t want to be small then there is no point in breaking down. He went to suggest that Sprints/Iterations are just artificial boundaries. My counter is that even when its difficult splitting stories still gives you several advantages:
- The Product Owner has more opportunities to change direction. With my signup example if supporting their own signup takes too long, the Product Owner may choose to drop the Twitter option.
- More frequent touch points with the Product Owner and Customer allow for better steering of the direction of the team.
- If the company changes direction mid-stream the larger the story the more WIP (work in progress) that needs to be either removed or finished up.
- Smaller stories allow more of them to be “Done” early in the iteration, allowing an earlier handoff to QA for teams that haven’t yet adopted ATDD.
- Large Stories make it easier to get lost in the details and fall down a rabbit hole (ask any of my team members at Databeacon).
- Large Stories make it more likely that we will bottleneck.
Finally I’m always being asked for more Story Splitting Examples. Think back 1995 when Amazon hadn’t launched, we’re developing the site that will become Amazon:
Original Epic: “As a first time user I want the to buy a book so that I can read it in my home”
To start let’s try splitting on Workflow:
- As a first time I user I want to add a book to my cart so I can buy it.
- As a first time user I want to checkout my cart so I can buy the contents
- As a first time user I want to enter my home address so I can get my book shipped home
- As a first time user I want to see the shipping costs calculated for my home address.
- ….
Maybe for calculating the shipping costs for all 50 states and 10 Canadian provinces is still too big. Then let’s split it again. In this case I’m going to assume that shipping costs are the same for certain groups of states/provinces:
- As a first time user I want to see the shipping costs calculated to CA, NV and AZ
- As a first time user I want to see the shipping costs calculated to NY, MA and PA
- As a first time user I want to see the shipping costs calculated to ON, MB, QC
Now a CRUD (Create Update Read Delete):
As a first time Amazon user I want to remember my address so I don’t have to retype it next time I come back
- I want my address saved
- I want to use my address when I next return
- I want to edit my address
- I want to delete out of date addresses
The first one is an example of story that isn’t “valuable” to user by itself. Nonetheless if it’s the only splitting possibility you have that it can still be useful.
Finally when do you stop splitting? At the lower end no smaller than two developers one or two days. Smaller than that and the stories have effectively become tasks. Update: After discussion with Tobias (see the comments), I think a better statement would be that teams should complete 5-10 stories a sprint. This forces the stories to be small without tying them to days.
Slides from a recent Webinar are here (pdf).
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.
Thanks for the cncrete exsamples. Nice. This statement bothers me though…
> Finally when do you stop splitting? At the lower end no smaller than two developers one or two days. Smaller than that and the stories have effectively become tasks.
This is ambiguous. What constitutes a story has nothing to do with number of developers or days. There is a BIG distinction between a story and a task, that needs to be acknowledged to understand this way of working. A story is a request that has business value (a WHAT/WHY), while a task is simply a thing to do, a step on the way towards the requested value (a HOW).
So my response when I get the question “when do you stop splitting” is “when you are no longer able to formulate the request as a (customer) value statement”.
I agree that a User Story has nothing to do with the number of developer days, but people still need some guidance when they start out about the lower bound for a story. If had phrased it better I would still use the number of days, but add that its not a story anymore its a task.
Your statement about “customer value” is right but will gives people an easy out to stop splitting when the story is still larger than a single sprint. I use people days to help people get a real sense of how small these often are. Otherwise I often find people who think that a Story taking a 2-3 sprints is ok.
Cheers
Mark
Ok – I like it consider it stolen. 5-10 Stories a sprint. As usual if I had asked what you do instead of defending I would have learned sooner 🙂
> If had phrased it better I would still use the number of days, but add that its not a story anymore its a task.
:-/ You did say that, and that is exactly what I contest. Making a story into a smaller story is utterly different to breaking a story down into tasks. I think you add ambiguity by discussing person-days, and lose the what/how distinction that is so vital.
When I work with teams, after explaining the nature of a story, I offer a guide of 5-10 stories per sprint. This makes it very clear that stories need to be small, and says nothing about how many developers will work on them, which is essentially unknown at the time of commitment and will emerge as the work gets done.
“5 – 10 stories a sprint” for how many developers working what length of sprint?
Ten stories sounds OK but is still not great for 5 developers working a two week sprint. Developers are good at math, and can quickly figure out that we’re talking about an average of 1 story getting done every 4 days assuming 25% drag or 6 ideal hours a day. The “5 – 10 stories a sprint” guideline would be pretty bad interpreted by a team of 9 developers working a 3 or 4 week sprint.
I understand the desire some have to keep time out of these discussions, yet I don’t think suggesting a range of stories for a sprint makes it any less ambiguous. I would think that here it makes sense to provide the advice in days. When coaching a team, taking into consideration the size of the team and length of the sprint, you could use a range of stories which I agree would be preferable. Maybe this example could be further amended to include a suggested team size and sprint duration for which 10 stories would be reasonable?
In my opinion you have to reverse the problem to come to the number of stories. If you burn down story points and you wish to see change (eg progress) regularly on your graph, you inherently need to finish about one story per day. So for a 10 day sprint, close to 10 stories. This is untied to the number of team members and gives a good target to work toward.
Dear Mark, not stolen, consider it a gift :). I have got great mileage from that simple statement — it generates a different kind of question.
Thanks for posting the article, I would like to point out that the story is something that describes ‘What’ is to be accomplished. The tasks are something ‘How’ it will be accomplished.
Once we start applying this criteria, it will be very clear when to stop creating smaller story.
As far as number of stories in an iteration are completely dependent on the length of the iteration as well as the number of people and their skills. But I would recommend that the team should be able to deliver a story every 2 or 3 days for acceptance. Some stories that may need more than 3 days, could be scheduled to be accepted later in the iteration.
Other aspect of ‘Splitting ‘ the story is the one that is not completed in an iteration but has enough value completed. So we split the story in two, with value delivered and task completed assigned to the current iteration and ‘incomplete’ part (with reduced points) gets moved to the backlog of the next iteration.
🙂
Santosh – thanks for your reply. I agreed with your comment right up until the end. That last case isn’t an appropriate use of Story Splitting. This is an attempt to go back and change history. The team committed to a number of stories. If they don’t complete that work, that’s fine but they don’t get to take credit for partially completed work. If anything that rewards over committing. Instead their velocity should just go up in the next sprint when they complete the work they committed to in the previous sprint. By continuing the current approach you just give the team a crutch and hide the real problem.
Hello Mark,
I agree that we should propagate the over committing of stories but as time and again we have found if the Product Owner makes the call that there is value delivered for the project, he/she has asked the team to split the story and more than 50% of the time, the remaining components were actually moved down in the priority. The customer satisfaction and working software are the main goals of Agile, how you get there is of less importance.
It is very similar to Kanban principle, keep the waste to a minimum.
Santosh
Mark wrote:
> Instead their velocity should just go up in the next sprint when they complete the work they committed to in the previous sprint.
Let’s consider that for a moment. In this case, the next sprint’s velocity will be decidedly too high. It can’t be used alone for Yesterday’s Weather. So, one solution is to use an average velocity. That makes the math work, but, to me, seems to let the team off the hook again. “So, we’ll finish it next sprint. What’s the big deal? It averages out in the wash.” I’m inclined to give zero points for the completed portion (this iteration) and come up with a new lower estimate for the remaining work (for next iteration). This makes Yesterday’s Weather seemingly too low and that will create discussion. It’s this painful feedback that serves to reinforce the need to meet iteration commitments. What do you think?
More importantly, not meeting an iteration’s commitments raises all kinds of issues and is best avoided.
Very interesting Andrew – I’d never considered it that way. I tend to use the trailing average approach, but I do see your point about letting them off the hook. It really depends on how you use velocity. I see it as a planning tool and way of seeing roughly how far you will get through your backlog before the end of the project. In that case I probably want the trailing average over 3 sprints. I would find another way to address the over commitment issue.