by Aki Namioka, Sr. Agile Consultant

Introduction

Estimating agile projects, especially within an organization transitioning from waterfall to agile, is a topic that can be rife with tension and opinions.

One source of tension is the desire to replace waterfall planning with something that is just as tangible. On a typical waterfall project a Project Manager has filled out a Microsoft Project file with ALL activities listed– often months ahead of time. The estimates are usually in days or even hours. However, as soon as this Project file is published, it is probably out of date. Spending days or even months on creating this Microsoft Project file is characteristic of a heavyweight methodology.

Agile, however, advocates lightweight methodologies. Scrum teams often use story points to estimate the work instead of hours/days. It is much easier for an agile team to estimate a 5-point user story, rather than estimating a 3.5 day feature. But a confused manager may try to map the story points to something they are familiar with and ask, “How many days is one story point?”

What the manager probably wants is the answer to these two questions: “When will the work get done?” and “How much work is left?”

The key to successful agile estimating is to find a balance between the need of the organization for transparency into the status of a project, and the agile team’s desire to stay lean and lightweight.

Story Points, Planning Poker, etc.

Most Scrum teams have adopted story points to estimate work, and use planning poker, or something similar, to reach consensus on the effort required to finish a user story. However, even though this practice is popular, it is not mentioned in the Scrum Guide. The Scrum Guide only says that a Sprint Plan should be created at the beginning of each Sprint. It is up to the team to decide the amount of work that be taken into a Sprint Plan.

That said, story points and planning poker are popular for several reasons. Story points are a simple lightweight system. Each team can create its own scale for estimating the effort that goes into completing a story. If the Fibonacci sequence is used to assign points (i.e. 1, 2, 3, 5, 8, 13, …), it is even easier for teams to use this system for estimation. Planning poker gives each team member a voice in estimating the effort. It will also quickly show if there are discrepancies on the teams for what implementing a story entails. The simplicity of both practices is in keeping with the agile culture of Lean practices and values.

Release planning and affinity estimating

With story points and planning poker, there is still the issue of answering the manager’s question: “When is it going to get done?” Though creating an up-front project plan for an entire project is impractical and inaccurate for most projects, many agile teams will do a lightweight release plan. This release plan will produce a mapping of user stories to Sprints for about 3 months.   The Scaled Agile Framework (SAFe Ò) has a version of release planning called a program increment (PI) planning. To support release planning, the team can do a quick first pass on assigning story points using “affinity estimating”, or something similar.   A team can sort all the user stories that are targeted for a release from smallest to largest. Keep in mind that this is easier for teams that understands their velocity. Once the stories are sorted it is easy for the team to put them into story point buckets of 1,2,3,5,8, … points.

After a Release Plan is created, the team can still revise the story point estimates while they go through their normal backlog refinement and Sprint planning.

Why do hours?

Some agile teams still want to add more granularity to their work estimates and will often add hours to the subtasks for user stories. This is often done during Sprint Planning, and tools like Jira will show a Sprint burn-down chart based on remaining subtask hours. This can be a useful metric for a team, to see how much work is left to complete a Sprint. This can be useful for new teams that are unsure of their capacity and velocity. However, this level of granularity does take more time to produce, so an agile team should weigh the cost-benefit of producing estimates at this granularity.

Experience with estimating:

As an agile practitioner, I have two stories about points and how my teams handled them. These stories illustrate why story points may or may not be useful.

Example 1

I was coaching a Scrum team that had been together for a couple of years, and we were working on adding features to a product that had been in use for several years. We were stable enough that we planned an average of 5 story points per person per Sprint. At one of our Sprint Planning sessions a developer said, “Why don’t we just pull the next 6 stories?” He explained, “We’ve been averaging 6 stories per Sprint for awhile”. I looked, and sure enough, he was right! As the team had matured, we were consistent in our velocity as well as consistent in story sizing. His insight saved us lots of time in subsequent Sprint Planning sessions.

Example 2

Another team was transitioning from Scrum to Kanban. Before our transition, we discussed which practices still made sense as we transitioned to Kanban. One practice the team decided to keep was story points. We were working on a new product with new technology, and the team felt that continuing the practice of pointing stories would help us create consistently sized stories.

Conclusion

Agile projects should decide what level of estimation makes the most sense and meets the needs of the organization. Whatever method is selected, two things should be considered:

• The estimation method should be as lightweight as possible and still provide the team with information they need to make decisions about Release Plans and Sprint Plans. This could mean no estimates at all with a stable team.
• The method of reaching consensus should give everybody on the team a voice in the estimation decision. Planning Poker is the most common method for teams using story points, but other practices exist, such as affinity estimating or “t-shirt “sizing.

A competent agile coach should be able to guide the team to adopt the estimation method that works best for them. It may change over time as the team matures. There is no agile practice that is cast in stone, including estimation methods.