I’ve heard as many explanations of story points as teams I’ve worked with. I’ve seen a team use equations to get from T-shirt sizing to story points to time prediction. Another team I worked with estimated user stories in story points and estimated sub-tasks (hello there, Jira) in hours. When I ask a team why is it that they estimate in story points, the explanation I typically hear is, “We’re an agile team.” In an agile environment we should be questioning what the value of doing everything we do, and we shouldn’t overlook estimation in our inquiries.
Complicated vs Complex
Complicated pieces of work are pieces that we know about. Mostly, we know what it is that we don’t about the work and therefore can have a good guess at how much effort it’s going to take for us to complete the work. If we’re really lucky this work can slip into simple and it comes to us almost for free.
Complex pieces of work are pieces that we don’t know about. Some things we may not be able to know anything about until we have a go at. If this is the case, we should be considering creating a spike to find out before we start work.
How do we as a team agree whether we think a piece is complicated or complex though? Story points. Over time, a team will start to understand that a large story point estimate means that the piece of work sits more into complex and less into complicated. Therefore when a team estimates work high up the story point scale, they know to look into the questions they don’t have answers to yet. A spike is a piece of work to quickly look into very specific questions in a set time scale. At the end of their investigation, the team should throw away all the work that they’ve done (so quickly that it should never be allowed into production) and bring the things they’ve learned into the original piece of work.
Another reason why the team may have estimated a piece of work high on the story point scale may be because the piece of work is just too large. When work is too large, people build in extra contingency into everything around that piece of work, including their estimate. These are a few questions the Scrum Master can ask the team about the piece of work to help them find out why their estimation is high.
- How much information do we have vs how much do we need?
- Whose perspective is the information written from?
- Is there a clear reason why the piece of work is being requested?
- Do we know exactly what the measures of success are?
Sometimes a team has everything they need and everything is clear, but there’s just too much to do as one piece. Like all large things, large pieces of work move more slowly than small pieces of work. Take a look around the web for ways to break down user stories. There are some interesting and creative ways to look at your work and find different ways to tackle it available out there.
If you think that refinement is your problem, perhaps think about facilitating some Three Amigo sessions in between formal backlog refinement meetings.
Something that should scare everyone in every organisation is how concentrated the knowledge of their organisation is within their organisation. I’m sure we’ve all heard stories of someone leaving an organisation and them being the only person who can <insert important function here>. As part of the refinement and estimation process the team must be talking to each other about what they collectively know regarding a piece of work.
When it comes to estimation, this typically manifests itself by the individuals having wildly different estimates. Ask multiple members of the team to explain their estimate and you may find out that one person has never touched part of the system and that another is the only person who has. What a better time than to invite the team to collaborate more intensely than they’re used to doing so that the knowledge can be spread out?!
Facilitating Estimating in Story Points
There are some gotchas of using story points that are easy to fall for if the facilitator is not looking out for them.
Only the Development Team get to estimate. Not the Product Owner, not the Scrum Master, not the boss. Only the people who are potentially going to do the work get a say on the estimate for that work. This includes BAs, devs, QAs, and anyone else who falls into the ‘does the work’ category.
We’re trying to find out what each individual thinks as an individual to understand the team as a whole. This means we need to avoid groupthink. I always provide teams with planning poker cards for two reasons. First, when a planning poker app is open and being paid attention to, then those twitter and facebook notifications are oh so appealing. Second, due to the nature of a phone, it is easy for one person to see what the person next to them has selected.
Ask the team to select a piece of work to discuss ready to estimate. Once there are no more questions about what the work, then we’re ready to estimate. Ask everyone to choose a card and place it face down on the table in front of them once they’ve chosen. Wait until everyone has placed their choice down, and then ask everyone to turn their card over and hold it up for all to see.
Check for disparity, and ask at least the highest and lowest voters to reveal why they chose these results. Once the discussion that innevitably start have finished, invite the team to vote again and guide them through the same process of placing a card in front of them and revealing as a group.
Check for agreement of a high estimate. What looks like high is different for every team, but typically sits around the 13 mark (5 – 20). Lead a discussion with the team to find out what their concerns are. Is this too big a piece of work, or does no one know enough about it yet? Perhaps only one member of the team hsan’t voted high, and that may be indicitive of a silo. If you’re ready to esitmate again, then do so.
If a concensus cannot be made, take the piece of work away for further refinement. Maybe you want to break it down, maybe you want to do a spike or two, maybe you need to do some knowledge transfer. Work out which, do it, and then bring this back to estimation and try again.
Once there is a concensus, you have completed the process and have a high confidence that this is a piece of work that you’re going to be able to complete quickly and with relative ease.
As you can see, story pionts can tell a team information about the work that the individuals that make up the team can find hard to uncover in other ways. Understanding the stories that story points tell us allows a team to use estimations as a valuable tool, and not just a reporting mechanism for their management.