Developers and story points

Table of contents

• What are estimations?
• Before a team estimates
  • Definition of Done
  • Team estimation vs. Individual estimation
• A story point is not a story point
  • Time Estimations
  • Complexity Estimations
  • Estimations based on the amount of work
  • Estimations based on the number of people involved
  • Document what your estimation process is
• What is the point of estimations?

A wild post-it note appears during a retrospective meeting saying: “We didn’t manage to complete the sprint again”. After a discussion, the team agrees that the solution for this problem is to “start estimating tickets” or “improve how we estimate tickets”.

Agile teams often use some estimation system. Surprisingly the Scrum guide, the official guide to Scrum, does not mention the word estimation even once. The guide to Kanban, or the Kanban “Blue Book”, goes even further by naming a chapter: “Estimation is a waste”.

“First, the team would stop estimating. He wanted to recover the capacity wasted by estimation activity and use it to develop and test software. –– Anderson, David J. “Kanban: Successful Evolutionary Change for Your Technology Business”.

Merriam-Webster defines the verb “estimate” as:

• to judge tentatively or approximately the value, worth, or significance of
• to determine roughly the size, extent, or nature of
• to produce a statement of the approximate cost of

This definition uses the words tentatively, approximately, and roughly. Thus estimations are not precise scientific measurements and, spoiler alert, should not be used to make promises regarding timelines.

Before a team can estimate a piece of work, there are at least two topics they need to agree on: Definition of Done and whether they use team or individual estimations.

Estimations will vary greatly depending on what your Definition of Done (DoD) is. To demonstrate this, let’s take a look at the DoDs of three teams.

The estimation of team A will be very different from that of team C, as the work required for the story to be done is not the same.

Team estimation means that the team members don’t estimate solely their work but rather the team’s work. For example, during planning, a ticket is discussed where the FE is easier than the BE. As a result, FE will vote with a higher story point upfront because they estimate the team’s effort and not just their own, including BE’s work.

On the other hand, there are individual estimations. In the above example, FE would vote for 2 story points, BE with 8. A discussion would follow the estimation. In the end, the team would agree on some number the entire team is happy with (usually somewhere in-between or the higher one).

My preferred approach is the former one. At first, this didn’t feel intuitive: How could I tell what story point is appropriate for other functions, like BE or QA? However, this way of estimating forces you to think about the entire work, not just your part, which makes spotting issues early on or raising more questions. It might always happen that any party forgets something the others might catch.

• How do you make sure that nothing is missed whenever talking about a ticket?
• What is the work that needs to be done for a ticket to be “done”?
• Do team members estimate all work or only individual parts?

The principle of Planning Poker is simple: instead of people openly saying numbers one after the other, they show a card with their estimation simultaneously. The advantage is that no one influences these estimations since everyone shows them at the same time.

When a person draws a 2 story point planning poker card: what does this number mean?

When it comes to time estimations, all parties talk about how much time they need to finish their part and if anything can be done in parallel. Then all times are summed up, and the final estimation is calculated. Time estimations can be nicely represented in Gantt charts. Most agile teams, if they do time estimations, convert time into story points.

“We’re estimating complexity” is a sentence I heard dozens if not hundreds of times. But what is this mysterious complexity?

The adjective “complex” according to Merriam-Webster means: composed of two or more parts and hard to separate, analyze, or solve.

It’s not a complex task to replace the background color of a button used in precisely one place and won’t break anything else in the app. But, on the other hand, it’s a complex task to update a dependency that has significant breaking changes, and you don’t exactly know what implications on the system are.

There are always some tasks that aren’t particularly difficult but very tedious. For example, you modify a component that is used in 200 different places. So you’d need to theoretically check out around 200 files and make sure the usage is correct. In this case, you might not be able to estimate complexity or time. Still, your gut feeling will tell you the approximate amount of work that will go into it.

Let’s say you have a ticket that only you need to work on. Estimating it will be pretty easy as you alone are in charge of making it happen. However, it becomes a little complicated when there is any collaboration needed. If a ticket needs both BE and FE, there’s significantly more going on. The parties need to agree on an API, or one party might be blocked by the other, or there is a chance that a requirement is misunderstood, etc. It becomes even more complicated when the dependency is outside of the team. So when it comes to estimations: the fewer people are involved, the lower the number might be in the end.

Whenever you speak about estimations, make sure the team has a shared understanding of this topic. Ideally, you’d have a document in your wiki specifying what a team is estimating with examples. It could be a document that has 13 user stories, one for every estimation. In addition, it might be helpful to look at completed tasks and use these as examples.

• What is your team estimating?
• Does only complexity influence estimations, or is it a combination of elements (e.g., complexity plus time plus dependencies in and outside the team)?
• Is there a clear and shared understanding of what each individual is estimating?

Before moving on, I want to point out once again: story point estimates are not a tool for planning timelines. Therefore, they should not be treated as promises.

Story points are an essential tool to align the team about the work to be done. They are an invitation to discuss a piece of work. They can show whether a ticket’s description is complete or if it still lacks some details.

Let’s say there is a story that looks very straightforward on the surface. When the time comes to estimations, though, there’s a massive variance in estimates: from 1 story point to 13.

• Is the person who voted 1 missing context?
• Did the person who voted 13 misunderstand a requirement?
• Why does the person with the 5 think it’s easier than the person who voted 13?

Talking about these questions is incredibly valuable so that a team can align on the requirements and implementation.

Finally, story point estimations can spark conversations about alternative approaches. For example, most people vote for an 8 or 13. At this point, people might start thinking about simplifying the task or splitting it.

One of the principles in the agile manifesto says:

Simplicity –– the art of maximizing the amount of work not done –– is essential.

Estimations are a tool that allows you to see pretty effectively if a team is aligned on the work to be done. Talking about discrepancies up front can save a lot of work and time. Or discover that the proposed solution is way too complicated and can be replaced with a simpler one. Use them to your advantage to deliver continuously valuable software.