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.
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.
It’s never about writing better requirements; it’s all about fostering collaboration. Read more about it in this article: https://medium.com/serious-scrum/what-not-to-do-with-user-stories-be38ddc76df9
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 ?
I came across Andy Bacon his blog that lists some interesting articles and resources, you can find it here: https://andybacon.com/agile-resources/
And just in case he ever decides to take his website offline, here is a quick mirror 😉
Some Agile Basics
- Agile Manifesto
- Agile Alliance Agile 101
- Scrum Guides
- Scrum Alliance About Scrum
- Agile Alliance Timeline of Agile Practices
- Agile Alliance Subway Map of Agile Practices
- Agile Uprising Coalition
- Ken Rubin’s Innolution Website
- Mike Cohn’s Mountain Goat Software
- Jonathan Rasmusson’s Agile in a Nutshell
- Michael James’ Scrum Training Videos
- Kent Beck’s “Extreme Programming Explained”
- DJA’s Lean Kanban
- Product Owner in Nutshell (Henrik Kniberg)
- Three simple truths
- Cotter Leader Change Process
Agile Related Certifications
- Scrum Alliance (CSM, CSPO, CST, etc.)
- Scrum.org (PSM, etc.)
- PMI (PMI-ACP)
- IC Agile (ICP, etc.)
- Lean Kanban University
- SAFe (SPC, SA, etc.)
- Oikosofy Enterprise Agile Framework
- Interesting matrix on scaling options
- Also check out the thought leadership from Leading Agile on the subject of scaling Agility
- Tools for Distributed Teams
Role of Managers in Agile
DiSC Assessment (free)
- Ball Point Game
- Name Game
- Penny Game
- Penny Game Modified
- Lego Scrum Simulation
- Innovation Games
Estimation, Data Driven Estimates, and Forecasting
- Free tools from Focused Objective
- Projectr tool
- Data driven estimates
- Some of the research around that great article
- Actionable Agile
- Affinity Estimating
Product Owner Resources
- Opportunity canvas
- Lean canvas
- Product vision
- Product roadmap
- Release plan
Random Helpful Things
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.
Read the complet blogpost here: https://www.mountaingoatsoftware.com/blog/story-point-estimates-are-best-thought-of-as-ranges
Carsten Lützen created a lot of introduction videos that can be found here: https://www.youtube.com/channel/UCDvr4dS873jCpYDCEtBBW8g/videos
Some exampels of these video’s are:
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
Use Progress Points to Identify Accomplishments
Read about it in this article: https://www.mountaingoatsoftware.com/blog/how-to-work-with-complex-user-stories-that-cannot-be-split