In our previous blog, we discussed a practical approach to developing an Agile technical design. Agile design acknowledges that a project is going to be flexible and evolving, and puts processes in place that allow this flexibility. The use of standardized design tools improves design efficiency and reduces ambiguity. And, as with Product Requirements Documents, best practices for fluid design documents comprise synchronized efforts that encourage sharing and collaboration. Design documents play a major role in the estimation process since they serve as the architectural “blueprint” for the product features being built. With a flexible design in hand, the next step is to estimate the work effort for your Sprint, or anticipated series of Sprints. In this article we present some handy tips that will help you master the elusive art of Agile estimation.
Why Estimates Matter
Good estimation is very important—it helps product owners optimize resources for efficiency and better outcomes. We recognize that estimation can be hard; it can the most difficult aspect of the project. Estimation must consider many factors that product owners must rely on to make decisions that affect the entire project team and the business – schedule, resources, budget and expectations. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. Without a good handle on estimation, project leaders and decision makers lack the tools needed to make the right business decisions and trade-offs. An accurate estimation process is a critical ingredient of the Agile development process, because estimates have a far reaching business impact across the organization.
Building Blocks of Agile Estimation
The two basics components of estimating are Product Backlog and Story Points The Product Backlog is a list of all things that need to be done within the Sprint. The list comes from the Project Requirements step [see our blog Practical Approaches for Documenting Agile Requirements] and is summarized in the Product Requirements Document. This list can be technical or user-centric (e.g. User Stories). The Product Backlog can be refined throughout the Sprint, if needed. New requirements can be added and existing requirements can be modified, defined in more detail or deleted. Requirements are no longer fixed early on; instead the final set of requirements within the Sprint is developed iteratively, together with the resulting product. In Scrum parlance, this process is termed Product Backlog Refinement.
Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. A story point is an abstract unit of measure of effort required to implement a user story. In concept, it is a number that tells the projects team about the difficulty level of the story. Difficulty is related to three facets: complexities, risks, and effort involved. Another aspect that goes into the Story Points based estimate is the business value delivered by the user story. If a user story delivers more business value to the customer, it is considered to have a higher story point value, even if its complexity may not be high. Story points are earned when the entire user story is completed and delivered.
Fibonacci sequence of story points is often employed when designating story points for user stories. The philosophy here being that the complexity of user stories can be thought of as additive blocks, therefore a user story can have 1,2,3,5,8,11 story points. There is some beauty and logic in using this approach as it mirrors the real life situation of how user story complexity can be constructed.
Task estimates in hours are the actual estimates of all the tasks that need to be completed for a given user story. For example, you could have a requirements analysis task, a design task, a development task and a testing task to complete a user story. Each of these tasks needs to be estimated based on the complexity of the user story. There is normally a good correlation between the story points of a user story and the estimates of tasks for the user story –because both are driven to some extent by the complexity of the user story.
Spikes can be used to drill down further on understanding risks and complexities. Initially defined in Extreme Programming (XP), and further evolved in the Scaled Agile Framework (SAFe®), Spikes are activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.
Approaches for Agile Estimation
Bottom up approach: Estimating work effort for Agile Sprints is fundamentally different from traditional methods of product development estimation. The traditional method is to estimate using a “bottom-up” approach where you identify all requirements and estimate the time required to complete those requirements. This information is used to develop the project schedule. Resources can then be assigned to tasks, and actions such as load leveling help to determine the final delivery date and budget. The “bottom-up” approach has some challenges. Design elements may be grouped in a way that may seem correct, but could be sub-optimal and/or lead to very different overarching rules. Further, there is substantially more detailed work to be done at this granular level and there are countless details that could be considered and developed.
Top down approach: In contrast, Agile projects, often employ a “top-down” approach, applying high-level estimation techniques on feature sets, then applying progressive elaboration and rolling wave planning methods to drill down to the task level on a just-in-time basis, iteratively developing more granular detail each level down. When estimating the high-level effort for user stories, you can use t-shirt sizing estimates – small, medium, or large. While the accuracy of high-level estimates may not be perfect, it is usually “good enough” to estimate the overall size of the effort for the project. The concept of rolling wave planning is that you plan project elements that are near in time in more detail and project elements that are distant in time at a higher level. The idea is that the later in time that a design element is, the greater the chance that it will change during that time, thus any investment in planning the details is likely wasted. Rolling wave planning is used to incorporate new information as it is learned, further refining estimates and iteratively elaborating with more detail as the project progresses.
Agile Estimation Techniques
Various high-level estimation techniques can be used by teams to develop story points. Agile estimation techniques are designed to be more expeditious than traditional techniques, but deliberately trade off detail and accuracy. Most Agile estimation techniques use relative units, rather than starting with direct estimates of budget or schedule. Instead, these methods use “points” or qualitative labels and simply compare the items being estimated to each other. Further, Agile estimation techniques are collaborative such that all appropriate team members are included in the process. Here is a brief overview of the most popular techniques:
Planning Poker is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of product development. Project team members make estimates by playing specifically numbered cards face-down to the table, instead of speaking them aloud. A Fibonacci sequence is used to assign a point value to a feature or item. The cards are revealed, and the estimates are then discussed. By hiding the figures, the project team can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.
Bucket System uses the same sequence as Planning Poker, and a project team estimate items by placing them in “buckets”. The Bucket System is generally much faster than other Agile estimation techniques such as Planning Poker because there is a “divide-and-conquer” phase. The Bucket System can also be used with larger groups than Planning Poker and with very large numbers of items to be estimated.
Dot Voting is an estimation technique that allows participants to vote their preferences among a set of items by placing a colored dot on items that they believe are higher priority than other items. Items with more dots are higher priority than items with fewer dots.
Affinity Mapping is the organized output from a brainstorming session, where an affinity diagram is developed to generate, organize, and consolidate information concerning a product, process, complex issue, or problem. Items are grouped by similarity, particularly where similarity is some dimension that needs to be estimated. The groupings are then associated with numerical estimates if desired.
Schedule and Budget
Once high-level estimates and team velocity are determined, the project schedule and budget can be forecast. A team’s average velocity should be estimated, and is used in forecasting a schedule. Average velocity is calculated by summing the velocity measurements from the team’s last 3-4 iterations for similarly complex or risky Sprints, and dividing that total by the number. Complexity and risk are qualitatively evaluated based on the estimation methods described above. If the project team has a track record of velocity, one could consider it to determine the most optimistic completion date, the most pessimistic completion date, and the most likely completion date. Budgets are then calculated by determining the specific project team working on the task, and multiplying loaded salaries (or billing rates) by the points of work. Budget forecasts and schedule forecasts are revised with each iteration. Retrospectives of previous Sprints encourages the project team to incorporate insights from past iterations, including the accuracy of their estimates. This is the key facet of the rolling-wave planning process that Agile projects ascribe to.
Best Practices for Agile Estimation
Story Points vs Task Hours: We suggest estimating user stories using story points and Tasks using estimates in hours. There is no need to get hung up on the conversion factor between the two, they are sort of apples and oranges. A story point is a somewhat arbitrary unit of business value, and it may not have a direct correlation with the task estimates. The task estimates (in hours) are the more critical measure as you will need that to estimate the project duration given a team capacity.
Collaborative Estimation: We recommend estimating in a team setting using a collaborative approach. This builds transparency, trust, ownership and accountability. This also leads to a healthy level of cross-checking and questioning that improves the accuracy of the estimates.
Heuristics: You can use a heuristic approach to quickly categorize user stories into segments based on complexity. You use a combination of your past experience and common sense to categorize and classify – allowing you to quickly estimate the user stories. This is an efficient technique for high-level estimation.
Skill Level: Definitely consider the still level of the person working on a task in choosing an estimate at the lower end or higher end of the acceptable range. In fact, we recommend making this an institutional practice by allowing a % buffer for junior level resources.
Fibonacci Numbers: While this is a good way to assign story points to user stories, don’t be hung up on this as the “silver bullet”. There is nothing magical about it. There are plenty of other simpler and easy to understand approaches as well. When estimating task hours, we do not recommend using Fibonacci numbers.
Adaptive Estimation: We recommend comparing past sprint’s actuals versus estimates to calibrate and benchmark the actual effort estimates going forward. This helps uncover any biases that may be creeping in systematically. This is a great practice that can continually help you fine tune the estimation process.
Fact Based Estimation: You should dig deeper into why an estimate is X number of hours, what needs to be done and what can be done to shorten it by leveraging the team’s knowledge. Estimates should be driven by facts based on underlying architectural and design components, not individual opinions and vague assertions. These facts need to be corroborated by the other team members in a team setting. This is a great technique for detailed, low-level estimation.
Sprint Retrospectives: Sprint retrospective sessions at the end of the sprint are a great forum to talk about the past sprint with regards to what went as planned and what risks or hot spots surfaced. This is a good forum to document the types of risks and unknowns that surface in each sprint, serving as a guide going forward when calibrating the estimation process where the risks and uncertainties play a key role.
Tools for Estimating
Single integrated tool sets are crucial to developing estimates, managing work effort, and benchmarking historical estimates (and actual time/budget expenditures) for use in retrospectives and future planning. Such integrated tool sets replace an ad-hoc process using spreadsheets, automate tedious tasks and provide insights for a holistic approach for project planning.
Key tool features include:
Automated task generation (from requirements) using custom templates that allow customization of specific tasks.
Automated estimation of tasks using a number of estimation methods, allowing increased efficiency, consistency, accuracy and transparency.
Granular burn down charts for each individual task and user story level.
Automation of documents, project plans and estimate reports that leads to a higher level of accuracy, transparency and consistency.
Automated what-if planning of resources versus duration trade-offs.
Closing Thoughts
As with the prerequisite requirements gathering and design steps, Agile estimation recognizes that a project is going to be flexible and evolving, and puts processes in place that allow this flexibility. Top-down, rolling wave planning enables this flexibility by incorporating new information as it is learned, further refining estimates and iteratively elaborating with more detail as the project progresses. Involving the full project team members is key–each team member brings a different perspective on the product and the work required to deliver a user story. Retrospectives of previous Sprints encourages the project team to incorporate insights from past iterations, including the accuracy of their estimate. Finally, integrated tool sets are crucial to developing estimates, managing work effort, and benchmarking historical estimates (and actual time/budget expenditures) for use in retrospectives and future planning.
What has been your experience with Agile estimation? What were some of the key challenges and lessons you learned? We would love to hear from you in the comments section below.