What we did
For some reason, we thought it would be a good idea to open up a debate in our Web Team around “What’s the point in estimating?”. It’s usually a hot topic in agile circles (#NoEstimates). We expected some strong points of view and a lively exchange of opinions. What we actually got was a good natured, rather polite room full of Engineers, Architects, Testers, Scrum Masters and Pod Leads, all making well constructed arguments for and against estimating.
We ran the session not with a hope of finding a definitive answer, but more to see if we had general agreement around why we might or might not estimate. Since working with Scrum, estimating tickets is something the Web Team at Holiday Extras has always done; and even before that, in one form or another, when working with Kanban or on projects.
So, do we actually need to estimate? When is the best time to estimate? Who benefits from estimation? Each pod uses a variation on estimating, but did that matter? Here’s a summary of a few of the arguments for and against that the team came up with.
In the red corner, arguments for
Each pod uses a different method, but that doesn’t matter; estimation creates and encourages conversation about a piece of work and ensures the whole team understands the approach and any issues they’d face in taking on a ticket. This is particularly helpful for new starters as the detailed discussion increases their understanding of the nature of the work and how the established team view that work (this may mean that in the short term, an estimate has to go up to encompass learning for those new starters).
If the discussion of the ticket is what’s important for the team, then the argument could be that we stop at the end of that discussion. However, we’ve found that putting a score on it - be that a Fibonacci, T-Shirt Size or even Time - helps compare the value and effort between tickets in a much clearer way. Fibonacci numbers of course help the Scrum Master and Product Owner establish Scrum Artifacts such as burn down charts.
Velocity is usually the main bonus of using a technique like the Fibonacci Sequence. An established team should agree on the effort of a piece of work and therefore amount of work they can pull into their sprint. Over time, this establishes a consistent velocity which helps the Product Owner create longer term roadmaps for work and the team ensure they don’t overcommit to work even when under pressure to do so.
Thinking outside the Scrum Team themselves, estimations help manage stakeholder expectations. It gives a tool to the Product Owner to help them assess when a project or piece of work could be done and whether or not it’s viable.
Estimation has many other pros:
- helps show if a ticket is too large and needs to be broken down into smaller, more manageable parts;
- assists setting sprints and makes it easier if there are scope changes later; and
- it helps show quickly if a project or ticket is beyond the scope of the team and therefore needs more people or time dedicated to it.
In the blue corner, arguments against
There was a feeling that a lack of flexibility in deadlines, particularly when dealing with third party or stakeholders, leads to forced velocity. There is no point in estimating if everything just has to be done.
Velocity only works as a measure with an established team, which is something that needs to be kept in mind if you have a team which constantly moves around, or changes the kind of work or platform they work on. There’s a variety in the way we estimate and with too many different methods it’s impossible to estimate effectively when joining a new team. What’s best? Do we need a Web Team “standard” to help when people transition teams? Context switching between methods of estimating when people move teams can be really difficult.
If teams are overestimating, there’s a danger how downtime is used: some downtime is great for supporting colleagues, doing personal development or planning future projects, but overestimating to create extra downtime does not maximise productivity.
Other arguments we encountered were that estimating in time increases expectations from stakeholders. It’s often incorrect and more of a guess and that often the Fibonacci scale becomes time in some eyes.
Estimating is difficult when you have a variety of knowledge and experience in the team. Do you estimate it based on anyone picking up the ticket? If you have work that one dev can do faster, pressure is on Product Leads to allocate work to that dev to get it done quickly, which decreases learning opportunities.
Essentially, it boils down to this: we can’t give you a definitive answer! There are many pros to estimation, but many organisations and teams proactively get just as much work done without estimating their tickets. Estimation is not a required method of Scrum, but the fact so many people think it is shows how powerful a tool it is. After much discussion, we believe, much like the rest of Agile, that estimation as a methodology adapts around us and how we like to work so there isn’t a one size fits all approach.
One thing we all agree on is that if you’re going to estimate, it must be done blindly either with cards or hands or written down. Otherwise you get bias towards the first number stated and that means that we don’t discuss the reason for differing opinions fully and potentially miss some detail about the work.
Shared understanding, we think, is the single most important and valuable benefit to estimation. Whether or not you then choose to attribute a tangible value to that work is purely personal choice.Tags estimates