As well-intentioned as teams are, it’s really hard to finish absolutely everything by the end of a sprint. A team may have grabbed eight product backlog items (typically user stories), but only finish six or seven of them. The other items are often close to done, but this isn’t horseshoes so close doesn’t count.
But what about the estimates on those unfinished product backlog items? Should they be re-estimated? And should the team get partial credit for the work they did complete? Let’s consider each of these questions, starting with partial credit. Continue reading…
User-story maps help Agile teams define what to build and maintain visibility for how it all fits together. They enable user-centered conversations, collaboration, and feature prioritization to align and guide iterative product development.
You can use storytelling to explain why slicing work is important. An colleague Rene de Leijer shared me the following story:
You are on holiday in the USA and driving already for hours on route 66 from the Grand Canyon to Las Vegas. Your stomach is roaring and your eyes are looking for a real American hamburger (sorry for the vegans). You see yourself eating one with both hands holding it in front of your mouth. And finally, in a small village, you see a strange burger cottage. Do you want to eat something in that weird place or keep on searching for another place to eat? But maybe that will take an extra hour. So yes you decide to stop and ease your hunger. The sign on the door says “Pull”, so you pull the door and it does not open. “Whahahaha” you hear someone laugh. You really feel weird on this and get a little but irritated, being hungry is not helping on this. You order a huge burger and the man behind the bar says “I will get you something in a minute, sir”. After 1 minute he puts a delicious piece of bread on a napkin and asks if you need some ketchup on your burger. And after my confirmation, he put some ketchup on the bread. After 3 minutes he puts an incredibly tasty burger on the bread, you really smell it and are eager to take a bite. “Sorry the burger is not finished yet” he says and my stomach is roaring all the time, while I am staring at that delicious piece of meat. 1 minute later, he puts some lettuce on top of the burger and only 2 minutes later some extra ketchup. “We are almost there sir” I hear him say. And finally, some onions and the last piece of bread are adding on top of it. “Well sir, now you can eat your burger, we have done everything in our power to give you the best burger you have ever tasted”. I pick up the burger and take a huge bite, and I spit it out, the bread is soggy, the burger cold and my hunger is vanished . How would you feel if you are this person, I think very disappointedly and he is leaving to find some other food? And do you see a comparison with our way of developing? Do you think the customer would enjoy if we deliver him every 2 minutes a small slice (top-down) of the burger ?
When estimating with story points, most teams use a predefined set of values that doesn’t include every possible number.
One of the questions I often get about story points is what to do if you can’t decide whether a particular product backlog item should be an 8 or a 13 (or a 3 and a 5). Part of the answer can be found by thinking about water buckets.
Suppose you have 10 liters of water you need to store. You also have an 8-liter bucket and a 13-liter bucket.
Which bucket would you store the water in?
The 13-liter bucket, right? Ten liters of water doesn’t fit in an 8-liter bucket. The water would overflow and spill out.
Extrapolating further, you’d use the 13-liter bucket for all amounts of water from 9 liters through 13 liters. Once you hit 14 liters, though, you’d once again need a bigger bucket.
And so it is with the values you choose to use when estimating stories. Think of each value as a bucket. A value bucket is used for all stories between that value and the next lower value.
Most user stories can be split. It may be hard to find a good way to split some stories, but most can be split. These are known as compound stories—stories that are made up of multiple smaller stories.
There is another type of story: the complex story. Complex stories are ones that cannot be split. They are inherently large or complex and there are no subparts to be pulled into separate stories.
Even with a complex story, you don’t want to let the story linger open for three, four or more sprints. Doing so
Makes velocity less predictable from sprint to sprint
Increases the risk of a developer going astray from user expectations , and
Allows the team to develop the bad habit of leaving work incomplete at the end of an iteration
It is common in the early stages of Scrum implementation for there to be misunderstandings about what User Stories are for and what makes them useful. A ScrumMaster’s task is to be able to help the Team and Product Owner when they are faced with ineffective User Stories as they go into Sprint Planning.