Jeremy Jarrell

Agile Made Simple

Tag: sprint planning

Using An Estimation Grid To Improve User Story Estimation

Estimation is tough. We all know it and we all struggle with it. Most of the challenge of estimation is due both to the abstract the nature of software as…

Estimation is tough.

We all know it and we all struggle with it. Most of the challenge of estimation is due both to the abstract the nature of software as well as the challenge of estimating something’s complexity. In fact, due to the abstract nature of estimating in story points, teams find that their goal is less often accurate or precise estimates, but more often consistent estimates.

Although we often struggle with assigning specific values to items we’re actually quite good at assigning relative values to objects. For example, few of us could glance at a bucket of water and estimate exactly how many ounces that bucket will hold. But, we could easily estimate that the bucket holds more ounces than a glass and less ounces than a swimming pool.

Teams can also apply this same relative estimation technique when estimating a particularly tricky piece of work. However, this is often done by estimating new stories relative to the size of other stories that the team has not yet worked on, such as other stories that have also been selected for the sprint.

While any relative estimation can be helpful, it can be more helpful to compare new stories to stories that have already been delivered and that the entire team agrees were estimated correctly.

Meet the estimation grid

One of the most powerful ways to do this is with the use of a tool called an estimation grid, which is simply a grid containing a cell for every other number in your team’s estimation range.

For example, if your team estimates using the values in the Fibonacci sequence from 0 to 13 then your estimation grid would look like this.

In each cell, place a sticky note representing a story that your team has recently completed that everyone agrees was indicative of its original estimate. For example, if in the last sprint your team completed a story that was originally estimated at 3 points, and everyone still agrees with that estimate, then place it in the cell for 3.

Putting the estimation grid to work

Once the grid is built you can begin working through your estimation routine as normal, such as by playing a few rounds of Planning Poker. However, once your team gets stuck on a particularly tricky story then it’s time to refer to the grid.

For example, imagine that your team is trying to estimate a story to add support for a new payment gateway to your ecommerce app. While the act of supporting the new gateway seems straightforward, it will involve touching a particularly complex piece of the codebase. For this reason, many of the team are unsure of how to estimate this story.

But by comparing this story to the reference stories already found on the estimation grid, your team is able to spot key similarities between this story and the reference 3 point story, such as a relatively straightforward set of business rules coupled with a complex area of the codebase. As a result, the team estimates this story as a 3.

Later, when the team finds themselves stuck on another story to add a simple CSV export to an existing report they return to the estimation grid. However, this time the answer is not as straightforward. While they find that adding this export seems more complex than the reference 1 point story, it’s not quite as complex as the reference 3 point story. But since the complexity of the story seems to fit neatly between these two reference stories your team assigns the story an estimate of 2.

Getting the most out of your estimation grid

While the estimation grid is already a powerful tool, there are a few things that you can do to get even more out of this tool.

First, resist the urge to use the estimation grid for every story that your team encounters. You’ll still want your team to be able to evaluate the complexity of each story through discussion and shared discovery rather than simply defaulting to comparing every story to the same handful of stories. Your estimation grid should be an aide, not a crutch, so only refer to it when needed.

Next, be prepared to update your estimation grid periodically. As the work your team is doing evolves they’re likely to begin working with different technology stacks, in different areas of the codebase, or with different themes of your product. Occasionally checking that your reference stories reflect these changes and replacing those that do not will help keep your reference stories relevant to your team’s needs.

Finally, resist the urge to create a cell for every value in your team’s estimation range. For example, you may have wondered why we didn’t create a cell for each value in the Fibonacci sequence from 0 to 13. There are two reasons for this. First, finding a canonical reference story for each value in that range can become tiresome, especially for those values that your team rarely uses. But second, and most importantly, you don’t want to paralyze your team with too many choices.

Generally, speaking humans make decisions easier when presented with fewer choices. For more on this, you can check out this article from Harvard Business Review, but for our purposes simply know that presenting your team with more choices to compare a tricky story to is likely to make act of the estimation longer rather than shorter. Instead, keeping your estimation grid simple and only giving your team just enough options will help keep the entire estimation process as painless as possible.

Wrapping up the session

Once your planning session is complete, a great way to wrap up is by laying all of your team’s estimated stories over your estimation grid and looking for patterns or clusters. For example, did it seem as if your team estimated the majority of their stories at the high end of your range? Larger stories are more complex and, as a result, tend to be less well understood. While a single large story in a sprint is unlikely to be a cause for a concern a sprint that’s primarily comprised of large stories is likely to be a very risky endeavor.

Or does your sprint seem to have many 0 point stories? While some stories may be so simple as to feel as if they do not warrant a point, no story is truly free. Every story takes time and attention from your team to deliver. While a few 0 point stories may not be cause for concern, many 0 point stories can add up and threaten your team’s chances of delivering everything they’ve planned for the sprint.

While the right answer is going to vary for every team, generally speaking I like to see most of a team’s stories clustered in the lower end of their estimation range. Stories this size tend to be just large enough that you can understand the impact that each story will have on our team’s velocity but are not so large to contain large amounts of unknown.

If your team’s sprint doesn’t seem to be clustered as I just described then don’t panic, you can simply take some of your larger stories and try to split them into smaller stories to reduce your risk. And if your team gets stuck estimating some of those newer stories then now you have a tool to help them.

Want to see more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on Using An Estimation Grid To Improve User Story Estimation

3 Ways Product Owners Can Help with a Great Sprint Planning

A great Sprint Planning session sets the tone for the entire Sprint. Your team leaves the session energized, excited, and with a clear picture of how to hit the ground…

A great Sprint Planning session sets the tone for the entire Sprint. Your team leaves the session energized, excited, and with a clear picture of how to hit the ground running in the new Sprint. But, what if things don’t go as well as you’d hoped? Then your team will leave the session tired and frustrated.  They will leave without a clear idea of how to get started on their new set of work. They may even leave without any idea of what their goal for the next Sprint even is.

If you’re a Product Owner, you may appreciate the importance of the Sprint Planning session but consider a successful planning session the responsibility of the Scrum Master. While this may be true, there are a few simple tricks that you can use to help your team get the most out of this critical ceremony.

Paint a Clear Picture

The Sprint Planning session is your opportunity to paint a clear picture of the upcoming Sprint and the objective that you hope to complete. But to do so, you must come prepared with both an engaging vision for your team as well as fully prepared to discuss the details of each Product Backlog item that you’ve selected to support that vision.

The details that you provide will be essential for helping your team appreciate the depth and complexity of the items that you’ve selected. And, it's these details that will help your team give as accurate of an estimate, as possible.

Mind Your Body Language

Just accept it, it's going to happen. Sometimes your team will throw an estimate on an item that’s higher than you expected. But when it does happens, how you react will play a major role in setting the tone for your relationship with your team.

On many teams, the Product Owner is treated as a figure of implicit authority. For this reason, it’s imperative that you be acutely aware of your body language, facial expressions, or any other behavior that may put pressure on your team to reduce their estimates.  Even if this pressure is inadvertent.

Pressuring your team to reduce their estimates won’t reduce the actual work behind the estimate and will only make your job harder.  This is because your own long-term planning lives and dies by the validity of the estimates that your team provides. If you pressure your team into giving inaccurate estimates then it will be your release plan that suffers in the end.

Instead of applying pressure, take this opportunity to ask questions. Why is the estimate higher than you expected? Or, what hidden complexity exists in the item that you didn’t see before? Taking the time to understand why the estimate is higher than you expected may reduce your chances of being surprised in the future.  In fact, it may even uncover an alternative path to achieving the same goal with less complexity.

Remember That Estimates Are a Forecast

Above all, remember that the estimates your team provides are a forecast…not a commitment. Holding a team to their estimates creates a culture of fear. And, in such cultures, your team will invariably begin to sandbag their estimates to protect themselves from the possibility of occasionally under-estimating an item.

Once this happens, your team will begin to continually pad their estimates to create a larger and larger margin of safety. The result, of course, being that the amount of actual work completed each Sprint will continue to dwindle.

But, there's an even worse casualty of this trend. Learning can only occur when a team feels safe enough to embark on experiments and learn from their failures. If a team is punished for every mistake then all learning will eventually cease. And, without the ability to learn, your organization cannot hope to compete in the world of product development.

Helping Your Team Succeed

The role of the Product Owner is easily one of the most important roles on a Scrum Team but is also arguably the most difficult. The Sprint Planning session is your opportunity to invest in your relationship with your team each Sprint. Because it's only with an ongoing investment in that relationship will your product see long-term success in the market.

Have you suddenly found yourself in the Product Owner role and want to know how you can use this role to help your team be successful? Check out my course series, Using the Scrum Framework, to learn how you can help your team reach their highest potential and deliver a great product to market.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

No Comments on 3 Ways Product Owners Can Help with a Great Sprint Planning

Type on the field below and hit Enter/Return to search