Perhaps one of the most hotly talked about topics with Agile is that of estimation. It can be used to drive a wedge between good natured people hoping to accomplish the same outcome or bring them together as they agree on sizing of backlog items to be worked on. Whatever happens, there are sure to be fireworks at some point in the process of estimation either from management, product or the team. The key is to make sure that certain basic practices are followed to ensure the best possible outcome when estimates are used to gauge our predictability for delivery. Let’s explore some ideas together.
Preliminary Estimate by Product Owner
Before even getting to the team level estimate, it is important for the Product Owner to have an idea of what they believe the size of the backlog item is going to be. This effort when done right also involves technical input from someone such as a Technical Analyst to help the Product Owner get an idea as to whether something is smaller or larger than other backlog items previously worked on by the team. This effort of having the Product Owner and Technical Analyst is called out specifically in “The Art of Agile Estimating and Forecasting” and can really help a Product Owner know roughly what to expect going into a discussion with their Agile Team. I always say that when you focus on the basics, Agile is really easy. When discussing the 3 C’s (Card, Conversation and Confirmation), that Conversation then becomes the baseline of understanding context for the backlog items between team and Product Owner. At that point, the common understanding thread of the open discussion between parties can help to make the estimates reliable as a forecasting tool.
Relative Estimates with the Use of Story Points
While there are many ways to estimate work, I have found over the years that picking something that allows teams to not overly complicate the estimation process is essential. For that reason, I have found that story points (with Fibonacci or modified Fibonacci) helps a team understand how much work they can complete in a set period of time. The discussion that should exist around any one backlog item is not as important as the comparative analysis that is done between items. I commonly ask teams when they are estimating with story points whether the item they are talking about is really similar to the last item they sized as a 3 or 5. Whenever that comparison is drawn it tends to unite a team’s understanding of the use of relative sizing.
At the very same time it is important to remember that it isn’t a single sprint that defines the velocity of a team but a rolling average over several sprints that gives a better indication of what a team can or cannot accomplish and thereby commit to on an ongoing basis when comparing similar work efforts. Many people believe that using time-based estimates can help increase the accuracy of estimates, but that couldn’t be further from the truth. In a podcast episode by Lee Henson titled “Time Based Estimates Are a Waste of Time” there is an example of painting a wall that he gives several hypothetical answers to how long it will take to paint a wall. Giving a baseline estimate becomes the true north for a team setting expectations with their estimation techniques. Using these common techniques becomes important:
Find a baseline item that is relatively small
Size that item as a 1 or 2
Size other items in relation to that baseline item
Compare other items for ensuing sprints in relation to other items already worked on
If for any reason the steps seem overly simplified, they are intended to be so. This is where using a simplified, hopefully pragmatic approach to relative estimation can make life so much easier for everyone involved. In a very recent podcast episode, this very pragmatic approach to estimation was discussed in the review of an article written about such techniques. The episode is titled “The Top 8 Agile Estimation Techniques That Do NOT Work” and reviews several techniques for estimation that can work in various situations but should always be looked at for what value is it providing for predictability. Ultimately, if it is not helping the team become more predictable in what they are able to complete, it doesn’t accomplish much for them.
Don’t Modify the Estimate after the Sprint Starts
Even after a team has completed their work in a sprint, I have commonly heard conversations such as follows… “That user story really wasn’t a 5, it was more of an 8.” Or “We should really check to see what the actual story points were after we finish our sprint, that would help our estimates be more accurate in the future.” Please for the sake of sanity at the very least, do NOT change your estimates after the time you start working on a backlog item. There are many opportunities to refine the backlog and change estimates leading up to the time that a sprint begins, but there is nothing that is going to detract further from the refinement process further than trying to “fix” estimates after the fact. They are just that… estimates or guesses based off of the information that we have available to us at the time. If anything, when we see backlog items that seemed much more complex than we originally thought we should be asking the following:
What are the acceptance criteria for the user story or backlog item?
Have we met the stated acceptance criteria?
If something has changed with the acceptance criteria, why is this not a new backlog item?
If we become accustomed to estimating the work that we currently are doing and the context in which it needs to be delivered, it will help us call out the work that goes outside those bounds for the sprint in which we are working. Exercising restraint to not just work on the additional acceptance criteria right now breaks the whole idea of incremental development and the goal for continuous integration and continuous delivery. Have those conversations with your Product Owner to identify when the ask has suddenly gone beyond the scope of the backlog item and take a stance to create additional items to get those acceptance criteria met so you can see incremental delivery each sprint.
Keep It Simple – Learn from the Past and Move Forward
Regardless of what you use in your estimation practices, the key is that we learn from what we have done to improve the future. Getting the Product Owner to provide an initial estimate helps gauge whether work will even fit into a sprint or multiple sprints. That input they gather from a Technical Analyst is in turn a check and balance before going to the whole team for story point estimations. Keep those story point estimations relative to each other and as the team learns from one sprint to another what their baseline items are, the estimates converge upon a velocity that the team is regularly able to attain. And finally, no matter how tempting it is to go back and modify estimates after the fact… DON’T. The estimates are sometimes a little bit high or a little bit low but they even out over time and as the team learns where they need to do more refinement before bringing a backlog item into their sprint. Let teams learn from their experiences and guide them as a result of those experiences to become more predictable in their completion of valuable solutions.
コメント