A deeper understanding on…
Estimation
Road to PSM III — Episode 14
In this episode I will cover various subjects related to estimation like predictability, transparency, inspection, adaptation, uncertainty, velocity and time-tracking.
What to estimate?
In Scrum, an estimate is one of four prescribed attributes of a Product Backlog item, just like value, description and order. They also often include test descriptions too.
“Product Backlog items have the attributes of a description, order, estimate, and value.” — The Scrum Guide
That’s pretty much all Scrum has to say about estimation in regards to the Product Backlog item. It doesn’t explain what the estimate actually refers to. In the section of the Sprint Planning it does however mention:
“Work may be of varying size, or estimated effort.” — The Scrum Guide
This “work” however is often defined during the Sprint Planning or the Sprint itself, but that is not to say it can’t be estimated during refinement. During the Sprint Planning:
“The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment.” — The Scrum Guide
I’ll argue that the definition of value (for an unrealised Product Backlog item) is an estimate too. So, the way I approach this subject is by stating that a Scrum Team at first estimates both value and complexity. To be more specific: the Product Owner determines value and the Development Team complexity and effort.
Predictability
Complexity is a core theme in Scrum. Scrum is designed to be applied in complex environments within which people address complex adaptive problems. It is meant for teams to optimise predictability and control risk. We covered that Scrum is based on the empirical process control theory. Remember the three pillars?
I have to disclaim that it becomes a lot easier to understand Scrum’s approach to estimation, if one has a good understanding of this fundamental theory.
Transparency
Estimates in this context serve to benefit these three pillars. This is why Scrum Teams estimate. But estimation in itself doesn’t quite cover it. A team estimates only as a part of the exercise to optimise transparency.
I am writing this series as an exercise to try and put into my own words why the guide says what it says. It’s a way for me to both help others’ understanding, but also to collect feedback so I can further develop my own. But in order to grasp why Scrum calls for estimation, one must truly first understand that transparency isn’t just a mushy word Scrum uses, but a fundamental theme. Transparency, for one, serves to benefit inspection (and visa versa).
Without this transparency, a Product Owner will have a tough time in ordering the backlog effectively. What’s more, the exercise of estimating is actually more valuable than its resulting estimate. When we collectively estimate, we are actually working towards creating a shared understanding of what is known at the time about both value (which reveals purpose) and complexity. Those teams that don’t care about collective estimation, will have this lack of transparency haunt them throughout development.
Complexity
Complexity can be revealed in numerous ways. An important variable to complexity is dependency. When dependencies exists, but are not known, there is chaos, but when they are known it reveals complications and complexities.
The more we adapt we become in creating clarity over dependencies, the better our decision making will be.
I can say something similar about abilities and skill. The more transparency we have over the level (and availability) of required skills (and tools and environment too), the better we understand how complicated something likely is and how much effort will likely be involved. That is why estimation is often a collective exercise, as Development Teams are cross-functional. Some teams will estimate (relative) effort, others complexity, or even both. Note though, they aren’t the same thing. Something can be really complex, but require little effort. Likewise, something can be really simple, yet require a lot of effort.
The Scrum Guide reveals a little bit more about the way we might approach estimation:
“Only what has already happened may be used for forward-looking decision-making.” — The Scrum Guide
This statement serves as a minor disclaimer that could have a big impact on how teams approach estimation, forecasting and projection. So inspecting what has been done in the past could both reveal complexities as well as serve to reduce it. This is an essential part of estimating.
Another important factor to weigh in is communication.
“Large Development Teams generate too much complexity for an empirical process to be useful.” — The Scrum Guide
As the above diagram illustrates, the more people involved with a Product Backlog item, the more complicated it likely is.
Yet another consideration towards determining complexity is the level of consistency. Consistency reduces complexity and thus optimises predictability. That is why it is important to keep the intervals, locations and timeboxes of events consistent. It is also important to have consistency within the team. When a team’s composition changes, a team will (temporarily) become less predictable, a conclusion everybody agrees with, but often fail to be aware of.
Value
Now, the Scum Guide distinguishes value from estimations and perhaps I rather would have the guide refer to it as ‘Value’ and ‘Complexity’ (both estimated and actual). But perhaps, in all likelihood, there is good reasoning behind it that I am not yet fully aware of. I can imagine that its writers chose to leave it completely out in the open as to how teams are to approach the concepts of estimate and value.
If time is a constraint, Scrum Teams will align on what can be done without compromising quality or value. If neither can be assured, the outcome would not be valuable nor viable.
During the Sprint: “Quality goals do not decrease;” — The Scrum Guide
For those looking for a deeper understanding on Value, I’ll refer you to this article by Christiaan Verwijs.
To estimate or not to estimate
We all estimate. It’s human nature, we estimate all the time, even when we are not aware of it. We also suck at it. A framework such as Scrum can help us become better at it; it can help us optimise predictability within complex environments. A #noestimates debate often boils down to the notion that estimates are always in play and are always a part of our continuous decision making process.
The more transparency we have, the better the continuous decision making process will be.
The better our sense of value versus complexity (and our ability to resolve complexity), the better we’ll be at increasing commercial profitability, efficiency and customer satisfaction.
What I will challenge is the way estimates are generally defined or the way they are often used. They are often used to create a false sense of assurance.
“Estimates are never wrong. They are an assessment on that point in time with what was known at the time. That reality proved to be different is another story. That doesn’t invalidate the estimates.” — Willem-Jan Ageling
What I will now talk about is not the practice of estimating or not, but about sharing estimates to others (like stakeholders). When those doing the work share estimates to those who are only involved, they set expectations. Whether we talk about estimates, guestimates, ballpark figures, projections, forecasts, sizes and what not, they will end up being treated as deadlines or commitments. Teams will try to meet them. It’s this phenomenon I condemn. Don’t allow estimates to turn into timeboxes or deadlines. Also remember that a Sprint’s timebox isn’t a deadline and neither is the Forecast a commitment. The timebox of a Sprint for one serves to keep the routine consistent, and to promote iterative development, enabling frequent inspections and adaptations… not to keep teams chasing deadline after deadline until they burn out.
When a Product Owner acts more like a business analyst rather than a value maximiser owning the product, a Development Team could end up trying to meet their given estimates. This could result in them rejecting potential valuable changes and dismissing or ignoring new insights (like better approaches), simply for the sake of meeting expectations. This will make a team rigid. It will not enable the team to create products of highest possible value.
A Scrum Team values optimising predictability over staying true to projections. Meanwhile they respond to change and value it. When they discover new complexities, they embrace it. In a way, they will learn to predict how much they are likely not able to predict. Sounds contradicting huh! Scrum can be like that. How do they do this? … they inspect. They inspect continuously.
Inspection
Working in consistent cycles enables a Scrum Team to measure its activities within those cycles and detect certain patterns and trends. A Scrum Team could for example keep track on how much time it spends on work they had not anticipated. This could involve their response to unexpected complexity, but also their response to changing priorities as either the team or customer discovers something new of top value. It could even inspect how much of those new discoveries disrupted planned work, and how much time was spent on replanning that work, including communication and refinement. How can a Scrum Team learn to be responsive to valuable change, without being disrupted in doing valuable work? It starts with those inspections.
As both value and complexity of Product Backlog items are estimated, this should be followed up with an inspection of what actually came to be.
Was it as complex and valuable as we thought it would be? And here follows the most important reason of why Scrum Teams estimate: they can learn from it and [trumpets blazing] adapt!
Adaptation
A Scrum Team adapting to those insights will enable them to become not only more predictable but to teach them how to produce more actual value by reducing complexity. These practices are embedded in the Agile Manifesto:
“At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.” — The Agile Manifesto
and
“Simplicity — the art of maximizing the amount
of work not done — is essential.” — The Agile Manifesto
The regularity of Scrum Events will enable Scrum Teams to adapt timely. The Daily Scrum doesn’t serve to teach teams to stick to the plan, but to make changes to it as more is learned during the Sprint. The Review and Retrospectives serve to enable the team to reveal actual progress and learnings consistently. They’ll teach the team to act upon actual experiences and discoveries rather than desired projections. If a Scrum Teams ends up somewhere different than projected… then this should be for the better! Thus, a Scrum Team should continuously reflect on its decision making. A Scrum Team could reveal and demonstrate to Stakeholders during a Review, how it chose to not stick to the plan, and how they are all better off for it. That ladies and gentlemen is true agility.
Uncertainty
Solving complex problems in complex environments generally involves developing creative solutions. It generally involves creating something that hasn’t been produced the same way before. As the Scrum Guide casually explains that “In complex environments, what will happen is unknown” and that we can only base our forecasts and projections on that which is known (from what has been done in the past), we could conclude that a Scrum Team will rarely be able to create projections that will be actualized exactly the way it was forecasted.
In complex environments, there will always be uncertainty. We could say that increased uncertainty equals increased risk. That said, there is also a risk in assuming certainty…which we are (unfortunately) very good at. Traditionally we create all sorts of by-products that serve this purpose like specifications and designs (and whatnot). The more assured we are, the less ready (or open) we will be to responding to new insights. So knowing we are somewhat uncertain, allows us to be slightly better at dealing with uncertainties.
reducing uncertainty
Sometimes a team will argue it cannot estimate as too much is uncertain. Discovering complexities in order to reduce uncertainties is an exercise in itself. Some will set timeboxes and call them Spikes.
The more we learn, the more we discover there is to learn.
Any indirect effort required to establish estimates will thus increase the total amount of effort. This is why some argue that, at times, a spike or pre-studies could be considered wasteful too. All this pre-work can incur the cost of delay, or even be used as a stalling technique. Another might counter this by saying that, without reliable estimates, a team could end up working on items with reduced or even negative returns of investments; which is wasteful.
Ironically, the need for precise estimates is often present in productions where ROI tends to be negative or marginal. It is exactly in those environments where I discover unhealthy pressure on Development Teams and dark practices. This statement isn’t exactly science I know, but my experience. I would like to hear about your experience with this too. It is in these environments where I believe a lot of time is wasted on artifacts and by-products; as these then serve to justify decisions or create a false sense of certainty.
Velocity
Teams often use a relative indicator for complexity and then measure the total on how much they are able to resolve each Sprint. This is not a prescribed or even recommended practice. Experience has taught us these can easily be abused as organizational management will pressure teams to increase their velocity. Some even (somewhat naïvely) set targets for teams to increase their velocity by x% over a period of time.
Velocity is often measured in total Story Points delivered. Story Points are indicators of complexity and effort. THEY DO NOT REPRESENT VALUE. So they do not represent the value being delivered, only complexity being resolved.
The ‘just get it done in time’ mindset generally results in just getting shit done too late.
Professional athletes spend a lot of time training how to perfect a seemingly simple move. A lot of effort goes into taking small steps/actions so they are done just right. This also involves learning which moves not to make. This may send them off to a seemingly slow start but sets it up for rapid acceleration. In Scrum, attempts to rush a team will slow them down, enabling them to take the time to do small steps right, in small but frequent increments, will speed them up.
“If we don’t take our time, while designing and developing, to do something properly, productivity will go down drastically and kill the project.” — Robert C. Martin
Time-tracking
I personally loathe time-tracking, though I do not reject it out of hand. Contracts may be time and material based, and thus require justification. Micro-level time-tracking is however a sure way to demotivate developers. It’s a discriminating practice. I am not sure why (especially in Software Development) we are so obsessed with practices like micro-estimations and time-tracking, but its toxic, control-freakish micro-management. I’m inclined to say that, if stakeholders want to inspect what developers actually do, they can inspect the work they actually did, rather than rely on timesheets and trendlines. Join the damn Review.
Hammering the need for those worthless sheets is hammering a lack of trust and involvement. If they want to know how developers are performing (and if they are truly working on the right things) they should either work with them, inspect their actual work, or trust them to do their job right, like they do theirs.
How to estimate
So some of you might have hoped or expected me to reveal my experiences with estimation techniques.
I hope though, that through this article, teams will understand that, at first one should focus on inspection. Estimates that are not based on inspections are generally worthless and wasteful. So first, I believe Scrum Teams should focus on keeping track of the work that is actually being done and what value it actually returns over time.
Establishing estimates (being part of Backlog Refinement) should primarily serve to create transparency within the Scrum Team.
It is only the Development Team, those doing the work, that can provide the estimations.
“The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.” — The Scrum Guide
The Scrum Guide doesn’t exempt the Product Owner from being involved. I believe estimating Product Backlog items should be a collective effort of the Scrum Team (as it serves to promote transparency).
Some teams will argue it is very time-consuming, but this might reveal they are doing it on too much of a micro-level, or that they are still dysfunctional in being cross-functional. Sometimes a team will constantly argue for more information. The more teams ‘fear’ wrong estimations, the more time consuming and frustrating it is to achieve collective estimates. To this, I can only say that estimates are always uncertain and that the level of uncertainty could be estimated too. When a team develops more stringent definitions on “done”, they will become more efficient.
At times I’d even argue that only creating a forecast could actually suffice, as it in itself is an estimate on how many PBIs a team expects to be able to do in a given Sprint.
Conclusion
Trust your team’s ability to address complex adaptive problems. Accept that you are working in a complex environment. Inspect what it actually takes to get it right. Adapt to what you learn along the way. And last, but not least, embrace the emergent nature of development. Scrum will enable you to collect feedback early and often. Understand that it will take a few iterations to get it right. So please, take the time to make it right. You will always discover better ways of doing it whilst you are doing it, or after you have done it. Your team’s ability to learn and adapt to this is far more valuable than your team’s ability to deliver reliable estimates. It is continuous inspection and adaption that will make your team more reliable over time; no estimation practise could beat that, but they could serve to support it.
I do want to stress that my understanding of why the Scrum guide says what is says is based on my own experiences. Much of it has been validated during my road to PSMIII and through engaging with you, the community. I hope to inspire you to do likewise and hope you will engage with me in this exercise.
For more on this subject, I recommend this article by Scrum.org
The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.
Next Episode:
