How #NoEstimates can help Agile Scrum Teams in few cases and scenario's

Why do teams estimate stories?

Most scrum teams use some form of story estimation. Story estimates, regardless of how they are estimated (story points, T-shirt sizes, time, Planning poker etc.), exists to serve 3 purposes:

• Help forecast customer value delivery
• Enable the team to gain deeper understanding of work and explore creative approaches of accomplishing it, facilitated through estimation discussion
• Enable multiple teams to co-ordinate dependencies

If your team is able to achieve these benefits, without creating a stressful environment or sacrificing team psychological safety, story estimates might not be a bad idea for you. However, in my experience, I think few teams struggle with story estimation.

Why do teams struggle with Story Estimates, and what are its after-effects?

Teams struggle with story estimates for a myriad of reasons:

1. Lack of clarity

Most teams feel uncomfortable providing a story estimate when the work is very different from anything they have done before, there are too many unknowns, or requirements are vague or dependencies with other systems/teams. However they are required to give an estimate before they can start working on the story. In such a situation, a good team would ask the product owner to provide more clarity, but sometime when that is not enough and still there are lot of dependencies, the team has 2 options:

• Succumb to the peer pressure and give an uninformed estimate
• Create a spike for next sprint to gain clarity and work on the real story in a later sprint

I think, creating a spike is fine, when we are able to complete it as per spike story timeline. Otherwise, I think Both these approaches aren't ideal since either we know the estimate is wrong and doesn't serve any purpose, or we just added a delay to the story's cycle time by at least 1 sprint. In this situation, while we might be able to realize all the benefits of estimation, it comes at the cost of delayed delivery of customer value, introduced as a side-effect of our estimation process.

2. Lack of common understanding of the unit of estimation

This is especially true for story points and T-shirt sizes because: people change teams and different teams use them differently; most people find it hard to marry complexity and effort when estimating; people often have different skills and relative complexity is different for different individuals; and more. As a result, the team is uncomfortable estimating and doesn't agree on an estimate even after multiple rounds of discussion. However, an estimate is put on the story anyway since we must move on with the estimation ceremony, and there is real work to be done. As a result, the team loses faith in the estimation process, and either everyone starts giving the same estimate out of apathy; or dominant voices takeover while others become silent due to a lack of psychological safety. Either way, everyone starts hating and dreading the estimation meeting. In this situation, not only do we not get any of the benefits of estimation, we also have now reduced their faith in scrum/agile, disengaged the team, and decreased the team morale & psychological safety - potentially giving rise to a host of new problems.

3. Misuse of story estimates

People misuse estimates either because they don't understand them, or because they are wrongly using it as a substitute for something that existed before they started working in an agile way. The most common misuse of estimates is to use it as a commitment or to use multiple team's velocities to compare their performance. Once we start doing this, the team either feels they need to pad their estimates because they will be reprimanded if they miss them, or they start artificially inflating them because they feel forced to increase their velocity. Either way, the estimates now become even less accurate than before, and you do not get any of the benefits you would have hoped for. You have also introduced fear in the workplace, which will eventually lead to a host of team anti-patterns.

4. Struggle with T-shirt sizes or time-based estimates:

If you are using a non-additive estimation technique like T-shirt sizing, it is difficult to realize the benefits of forecasting or work co-ordination across multiple teams.

Regardless of the reason why your team might be struggling with story points, the struggle itself creates an environment where the team feels uncomfortable estimating stories, but in most cases is forced to do it anyway.

How can a team realize the benefits of story estimation while maintaining employee engagement - #NoEstimates?

While estimation does offer some good potential benefits, it is often difficult to realize them, and creates a number of anti-patterns. An alternate approach can be to abandon story estimates altogether - an approach popularly known as #NoEstimates. For teams that struggle with estimates, #NoEstimates can often help them achieve all the benefits of estimation, while reducing the risk of disengaging team members! Let’s discuss how.

How does #NoEstimates achieve all the benefits of story estimation?

1.   Forecasts: It is widely known that the further the forecast in time, the more uncertain it is (cone of uncertainty). As such, it is futile to try to accurately forecast anything beyond the near future. Scrum teams plan their work one sprint (1-4 weeks) at a time. It is also a good practice to have the product backlog prioritized and have the next 2 sprints roughly planned out, in case the product owner is unavailable and the team has bandwidth to work on additional stories. So, at any point in time, the team should be able to tell you what is planned for the next sprint with a high level of certainty, along with a rough idea of what might be coming up in the next 2 sprints. In addition, many teams often engage in big room planning/ PI planning/ quarterly planning or some other form of multi-sprint planning effort to get a high-level view of how they plan on delivering value to their customers. Although less concrete than sprint planning, this effort combined with the just in time sprint planning and backlog refinement sessions enables the team to provide decent forecast for the customer value they will delivered in the near future (almost 3 months). Anything beyond that time-frame is too far to be forecasted with certainty anyway.

2.   Enabling deeper understanding of the work to be done: To ensure the team has a good understanding of the stories, and do not start working without giving enough thought to all aspects of the story, we only need to ensure that they are having the right conversations. In my experience this can be achieved without story estimates as long as the team has good psychological safety, shares a growth mindset, has a decent level of technical skill, is passionate about their work, and has invested in good story slicing practices. Now first to acknowledge that not all team share these attributes but leave aside the topic of estimation for a minute, and you will see that these values are pre-requisites for any team to be successful at agile! I believe teams adopting scrum, often get too focused on following scrum practices, at the cost of neglecting values that foster collaboration and enable agility, like the ones listed above.

3.   Inter-team co-ordination: The first step is to reduce dependencies. This can be accomplished by restructuring work and teams, and while it may not always be achievable, striving towards it makes most teams a better version of themselves. As the team strives towards this goal, they still need to manage the dependencies they have on other teams. Fortunately, we do not live in a world where someone marks a dependency in a tool with a deadline and disappears till the day they need it. What usually happens is that teams that have a dependency will communicate their needs to each other, break down the request into appropriate stories, and the product owners/scrum masters of all the involved teams will co-ordinate with each other, accommodating for competing priorities. You can use a technique like dependency map for this; updating it and communicating with each other continually as priorities change. Once the relevant work is pulled into a sprint, the teams will then co-ordinate with each other using scrum of scrums or some other continuous feedback/planning technique till the dependency has been eliminated. Notice, while this needs good planning, story slicing, prioritization, and communication, it does not necessarily need story estimates. People often use estimates to gain confidence in planning, but in an environment when we are trying to deliver the highest value to the customer on a regular interval and deadlines are more of an exception than the norm, good planning can be done without detailed story estimates, as long as we are good at decomposing the work into decently sliced stories that follow the principles of INVEST.

How does #NoEstimates increase productivity and Innovation?

#NoEstimates increases employee productivity and innovation by helping teams avoid frustrations arising from the discomfort they might experience when forced to provide story level estimates.

How do you apply #NoEstimates in an environment with deadlines?

Although we live in an agile world, there are some situations that come with a deadline. An example is environment driven deadlines - compliance, tax season, end of fiscal year, new year, time-sensitive opportunity, etc. Traditionally we have used story estimation to understand the size of the work and forecast if we can do it before the deadline. However, another approach to get to the same result could be to just brake down the work into small, roughly equal sized stories, and use the formula:

Total number of stories / Avg. Throughput per sprint

This will give you the number of sprints you need to complete the work.

Most people get concerned when they look at this formula because they fear that they will be unable to slice stories to roughly be the same size and still be useful. This is such an interesting topic that it deserves a separate article (which I will post soon too). But for now lets just leave it at - this concern is not as big as it may seem at first.

Is #NoEstimates for everyone?

No. For a team to be successful at #NoEstimates, the following conditions need to be true:

1.   The team has good story slicing skills and writes stories that follow INVEST

2.   There is a high level of psychological safety on the team to allow for constructive conflict, and the team has a strong sense of accountability

3.   The team has a decent understanding of advanced agile concepts and good practices like planning onion, dependency maps, backlog prioritization, etc

4.   The team works in an agile environment where hard deadlines are more of an exception than the norm

5.   The team is in the Performing or later part of the Norming stages when you consider Tuckman's team development model

6.   It helps if the team has a reputation of delivering good quality work on a regular and frequent cadence

In addition, there might be other factors that are unique to your team that you need to consider before adopting #NoEstimates. Every team is different, and like most things, you should use your own good judgement to make this decision.

Conclusion

While not applicable in every situation, #NoEstimates can be successfully applied for most agile situations. For the situations where #NoEstimates is a good fit, it helps teams increases productivity and innovation by helping teams avoid frustrations arising from the discomfort they might experience when forced to provide story level estimates. Not only does #NoEstimates deliver on all the benefits that most estimation techniques promise to achieve, it also ensures that the team is adopting other good agile behaviors like - growth mindset, psychological safety, good story writing and slicing, maintaining good backlog health, etc. Agile teams can use #NoEstimates as a good aspirational goal or a guiding tool to not only help with agile estimation, but also enable them to continuously improve and become a better agile team.

TLDR;

• The context of this discussion is an agile environment where teams are continuously trying to innovate, and the nature of work would be categorized as complex if one were to use the Cynefin model of complexity
• Story Estimates are never accurate, but if done right serve three benefits - rough forecasts, inter-team co-ordination, and deeper understanding of the work through conversation
• Most teams struggle to realize these benefits because of a number of reasons, but feel forced to go through the process anyway. This in turn creates frustrations within the team, that makes them disengaged, less productive and less likely to innovate
• While not applicable in every situation, most agile teams can realize the benefits of estimation without estimating every story as long as you build skills in other areas that you should be good at anyway to be a successful agile team, like - good story writing & slicing, maintaining a well refined and short backlog, focusing on throughput & cycle time, enabling teams to independently deliver end-to-end functionality, dependency management, and creating an environment of psychological safety within and outside the team
• #NoEstimates increases productivity and innovation by helping teams avoid frustrations arising from the discomfort they might experience when forced to provide story level estimates.
• While deadlines are more of an exception than the norm in an agile world, they do exist sometimes, especially when they are market/environment driven. The good news is if we follow good agile practices as listed above, we should be able to solve for this situation too without having to estimate stories

Thanks for reading it. :)