The Point About Story Points
My Estimation? We Suck!
Let’s admit it, we suck at estimation. No matter how hard we try, we just can’t get better. I remember many treks where we’d be fatigued and ask a friendly villager, “How much longer?, Just around the corner, 15 minutes tops!”. “Are we there yet?” is a rite of passage for every parent. You don’t need to be Einstein to figure this relativity out!
In a professional setting, bad estimation is rampant. I regularly challenge my teams to deliver on their commitments and it takes a lot of doing and discipline to get teams to deliver on a regular cadence. This is a real problem. Unfortunately, I’ve met few people who acknowledge this as a serious issue. Delivery is just supposed to sort of happen.
On the contrary, I meet people regularly, all decision makers who routinely ask for estimates, get bullshit estimates in return and the organization and the team suffers and works ridiculous hours to meet an ever shifting deadline on a never ending project. Yes, that’s you. This is a very costly problem.
When I took my first software engineering course, I got handed the “Mythical Man Month”, which talked about man months, I’ll call them person months. It didn’t quite sink in till I became a manager for the first time and had to give estimates to my manager back in the day. All the time spent in the trenches coming up with those estimates, modifying Microsoft Project files and their allied spreadsheets and pointless meetings about deadlines were like getting my teeth pulled! It’d be worth it if it actually helped us figure out how long things would take and those numbers were half-way correct!
It became apparent to me that this person month thing was bogus. You could never meet your commits, over time, as experience set in, the bullshit estimate got better, but it was still bullshit. It became S.W.A.G.. Long project cycles meant tons of time wasted and opportunities lost. Working like this is just no fun!
Agile was a real eye opener personally, it formalized so many techniques that I had been using in some modified manner, informally, to tweak my team processes, to extract productivity. The one part that remained challenging was the concept of Story Points. In every Agile training that I’ve been to, or have given, this is the part that gets the most questions. It’s not obvious and most people are inclined to dismiss it as one of those things that you could do without, which, in my opinion, is a lost opportunity to fix the estimation process.
Personally, it took a bunch of iterations for the concept to sink in and to understand how the Story Point concept is so radically different from the person months black hole.
In this piece, I’m attempting to try and explain how a team might use Story Points. This is how I try and explain it to my teams, which over time has tended to go down easier with each repeat rendition! Perhaps, this might encourage you to switch to SP’s as well.
What it is
Story points are a way to measure team “velocity”. A popular choice is to use the Fibonacci series (1,2,3,5,8,13), I recommend my teams to have an upper bound of 13. Something rated 8/13 SP is a ripe candidate for splitting into smaller stories from my experience. It’s also a smell that can tip you off to the underlying uncertainty in some cases, which can help Product Owners refine and re-focus the story at hand.
Here is a play-book to get started:
- Start by committing a team velocity. This must be reviewed and adjusted after each sprint, either upwards or downwards in small increments only after at least two sprints of consistent delivery. The idea is to converge to a real number, starting with an ad-hoc value.
- Do not take on more items than your team velocity. Move the remainder tasks to the next staged sprint. “Staged” sprints are what your product owner will create based on your velocity for the next sprint.
- If you end up going faster, take the next priority item from the backlog. Focus on picking up an item that you can finish if possible. This might not be the most high priority item depending on the time left. This is a great time to pay down tech debt, if you cannot reliably finish an item in the time remaining.
- The committed velocity is always a function of the entire team being present for the full sprint. If you’re short handed, then reduce the velocity by an ad-hoc number, since you will discover this true value as well.
- Story points are always relative, relative to a similarly sized item that you’ve attempted in the past. If you’ve never seen anything like it, you will end up giving a higher SP
- Story points are for the FULL effort — coding / testing / reviews / deployment. Don’t just estimate it from your perspective as a coder / QA.
- SP’s can only be given by the team that will execute it, product owners cannot SP. Skin in the game!
- SP’s must be collected via planning poker. This is a simple exercise where one person counts down from 3, and at the count of 1 — everyone holds up fingers to denote the weight. Remote teams can use Slack / Hangouts etc. during this phase.
- If there is divergence, reconcile the highest and lowest SPs, which will trigger a conversation that will divulge more detail about the task at hand. Stick to 2 rounds tops, if there is still no convergence, see if the group will agree to a pessimistic SP. It’s entirely possible at this stage to ask the Product Owner to add more details or request a technical spike instead of the item, to aid in arriving at the right number.
- When faced with divergent SP’s pick the pessimistic SP number and move on, versus repeat planning poker rounds. Timebox! Timebox!!
Story points are not raw hours. Story points are not weeks, they are a made up metric.
The following is a rough guide for SP’s, it’s not recommended to use such a guide, but as you start this process, it will help your team to start somewhere and then converge.
Remember that this is just a guide to get you started, SP’s DO NOT conform to anything real — in terms of a real # of hours / days etc.
- 1: Done within hours
- 2: Typically 1–2 days
- 3: 3–5 days
- 5: 5–8 days
- 8: 10 days
- 13: will span multiple sprints and should be broken down into smaller stories
Story points are driven by the following factors
Complexity / Uncertainty / Risk
- Complexity : Is the task at hand super complex, does it require knowledge of specialized algorithms or a code-base that is hard to understand or you’ve never seen it before
- Uncertainty : Relates to whether all aspects of the task are known to you before you start. Lets say that the requirements are vague or will change as you work on the item, then there is high uncertainty. Items will very clear acceptance will usually not be uncertain. That’s why it’s important to have very clear acceptance
- Risk : A work item might be simple, but it might be a risky change. E.g. Changing an invoice API’s will trigger a bunch of regression testing that takes time
The ultimate goal is to keep learning and developing your own system of estimation so that we get better over time.
The meta of using Story Points is of course, that each team is different, it’s made up of real people and not robots that work non-stop for 8 hours x 20 work days. Teams need to find consistency, and can tweak up or down depending on what gets them to be consistent. There are holidays, sick days, and all sorts of other distractions that can bust your productivity.
Numeric story points work best in my experience, over T-Shirt sizes lets say, since it lets people wrap their heads around a numeric value, it makes it easier to grasp and is an easier sell for the person hour crowd.
Ultimately, consistent teams are what gets your innovations in the hands of your customers in a timeline that makes sense. An estimate based on an SP process where teams have been practicing it for some time, is a reasonable approximation of when things might pop out of the pipe without killing your team and tearing your hair out about when deliveries will happen!