If you can’t measure it, you can’t manage it. – by Peter Drucker
Planning and estimating work plays a major role in transitioning your projects and teams to Agile ways of working to negotiate the challenges of the VUCA (Volatility, Uncertainty, Complexity, Ambiguity) world. Agile ways of working supports continuous need to meet customer demands by delivering in frequent and rapid cycles, frequent introspection and adapting constantly to stay relevant and let customers find our offering meaningful all the time. Estimation techniques bring reality checks. It sounds exciting to deliver whatever is needed but a very important element in today’s world is to ‘Fail Faster’.
Let’s be real, we live in the world of constraints
John C. Maxwell has rightly said, “Fail early, fail often, but always fail forward.” In terms of project management, we call it the MVP mindset. MVP stands for Minimum Viable Product. It is not about creating whatever it has been asked but delivering ‘just enough’ which can solve customer problems (desirable), may also be helpful for the business to grow (viable) and should also be possible for the engineering team to develop (feasible). Estimates help us to bring in such sanity which guard us from being overwhelmed and protect us from doing what we want irrespective of knowing what is actually desired by customers and also our budgetary constraints.
‘Agile Estimation’ is the term coined to describe such techniques which can help us in measuring the work we know and also the continuously changing requirements. We will discuss various agile methodology estimation techniques in this blog. The challenge in hand is not just measuring the amount of output but focus on the amount of effort involved into delivering the outcome.
Almost everyone is aware of the essence of the Iron triangle – Time, Cost, Scope & Quality.
You might be literally dreaming if someone comes & says, “You have all the time and money you need and you may do whatever you want and who cares how good and bad it is”. When the money is on the table, we need to know that in the dynamic environment, we may need to follow few rules –
Never fix all the three
- If scope and time are fixed, then you may ask for as much money you want
- If the time and cost are fixed, then make sure the scope must be negotiable
- If the scope and cost are fixed, then time should be flexible
- Quality should never be compromised but at times you need to foot down with trade-offs
How do we do Agile Estimation?
If you are using the Scrum approach then we need to know that few constraints are already supporting it. Like –
- The duration of sprint & the size of the Scrum Team are fixed
- This way the cost per sprint is fixed
- The scope is also fixed as it is expected that during the sprint the scope shouldn’t change and that is also a basis for deciding the size of the sprint
- While we iterate, we also focus on continuously delivering value to customer
- During the product discovery session, we also identify the first go-to market strategy and that iterate to achieve those MVP goals
- The work could be identified using any technique like days, story points or t-shirt sizing
- The focus is always on outcome and Definition of Done (DOD) helps us in staying aligned to it
- Velocity helps us in knowing the productivity
- The velocity is derived based on summing the units of work that has met DOD and that implies the focus towards the doneness of work and not just finishing a portion
Let’s zoom-out and understand the high-level estimations
It is important to zoom-out before we explore agile estimation techniques in detail.
From a sprint perspective, overall time (sprint duration) and cost (team size) is fixed. That means the iteration is always timeboxed for 1, 2 or 3 weeks at the start as well as the team composition. The variable which is negotiable is the scope. So the effort estimation techniques in agile are all about identifying what scope can be delivered at the end of each sprint/iteration . To derive the scope which is captured in product backlog in the form user stories, the size of the product backlog is estimated. Product backlog is then prioritised and sprint backlogs are created keeping the bite of the burger approach in perspective. Agile teams do a lot of multi level planning which needs to be more emergent than upfront. The plans should become more detailed as the knowledge about the requirement is clear.
In traditional project management where upfront detailed planning is emphasised. Requirements are analysed by capturing resources (human, infrastructure, software) needed and by using work breakdown techniques to estimate the work and duration needed.
Agile estimation is about estimating the size of work items or requirements which are loaded in Product backlog to derive duration needed to finish the work in ideal days or story points. Estimation happens at various phases in a project. We will share a list of agile estimation techniques in this blog and discuss them in detail.
Estimation at a very high level is done when we start planning the portfolio during the discovery phase to understand the size of the epics. During the discovery phase the breadth and the depth of the requirements are gathered in the form of epics and user stories.
Future releases are identified. At this point when the release candidates are identified the epics gather more information. The size of the epics are estimated and re estimated (if needed) . Once the release starts the subsequent sprints iteration’s user stories are estimated in Sprint backlog refinement.
Agile estimation principles
The first principle is that you must not fool yourself and you are the easiest person to fool. – by Richard P. Feynman
Everything in life is bound by a set of principles or guidelines. Similarly below Agile estimation principles must be adhered to when planning the product backlog.
- Estimates are not absolute – They are always relative and compared to similar size of work items in the product backlog.
- Agile Estimations shouldn’t be done in isolation – Collaboration and brainstorming with the right people who are involved in implementing the requirement/user story must be encouraged
- Incorporate uncertainty, complexity and effort while estimating a user story story
- Estimates of epics and features are more uncertain as the information in epics is at a very high level. The user stories are very detailed and their estimates are more specific than epics
- Preliminary discussion around user stories/epics is necessary in estimation techniques in agile scrum
- Re-estimate whenever the information on a user story becomes clearer
- Do not re-estimate once started i.e. the finished user story/epic or a partially completed story
Who participates in Agile estimation activity?
“None of us is as smart as all of us” – by Ken Blanchard
The key to having outcome based agile estimation is to include the right people at the right time to make right decisions and having the right kind of information to help project the size of product backlog/user stories.
Below roles should participate in Agile estimation –
- The Agile team (Developers, Quality controller /testers) – The doers estimate the work
- Solution leads/SME’s/Architects – Help provide technical clarity to the doers
- Product owner/BA – Help provide functional clarity
- Scrum Master – To help in facilitating estimation sessions and reinforce he agile principles and agile estimation techniques to any new team members
Agile Estimation Techniques
Listed below are different Agile estimation techniques that are used based on the project scenario. Any of the below different agile project management estimation techniques can be used based on what level of planning is being done. For example during high level portfolio planning T shirt size agile estimation techniques can be used. During release planning T shirt size or Fibonacci series can be used. During detailed iteration/sprint planning the team can use Planning Poker which is one of the best agile estimation techniques. This Agile estimation techniques list will come in handy for ready reference and quick comparison.
Three point estimate
In this method, the team needs to measure time/effort based on following parameters
- Optimistic Value (O) – How much time/effort will it take if everything is on track?
- Pessimistic Value (P) – How much time or effort will it take if things fall apart or there are impediments on the way?
- Most Likely Value (M) – What is the most likely and practical estimate to complete the taskE= O + P +M / 3 or Pert Estimate = O + 4P + M / 6
Of the two formulae for the agile effort estimation techniques, PERT Estimate is recommended as we give more weightage to Most Likely Value of the estimate.
Planning Poker
This is one of the most used estimation techniques in Scrum used by the teams while estimating user stories. Planning Poker uses cards to provide estimates. Here’s what happens in the planning poker technique
- Base Story is identified by the team by picking smallest story from the backlog, which is easiest to implement, no uncertainty, and least effort to implement
- Team picks a story to be estimated . Discussions on what is the work, what is the approach and technicalities along with dependencies and uncertainties take place
- The team has the Fibonacci series with them eg: 1,2,3,5,8,…Team members are asked to give a number for the story. Team discusses the effort, complexity, and uncertainty. The question asked here is “How big is this work when compared to the “Base Story”?
- Team members are asked to reveal the value of their cards
- Story point/Effort is then decided based on 3 scenarios
- Bingo – This is scenario where everyone in the team chooses the same number. Then story point/original estimate is the number given by the team
- Neighbours – If the minimum estimate we have got from the team members and the max estimate we have got are neighbours in the series we go with the max number giving the benefit of the doubt(Example: Dev 1 gives estimate as 3, Dev 2 gives the estimate as 5, we will consider the estimate as 5)
- Non-Neighbors – If the minimum estimate and the maximum estimate team members gives are not neighbours in the series, we go with the max number giving the benefit of the doubt, in this case we have another round of discussion and take consensus from the team(Example: Dev 1 gives the estimate as 3, Dev 2 gives the estimate as 8 – Go for the further discussion)
Fibonacci Sequence For Story Point Estimation
The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21 and so on, with each number the sum of the preceding numbers. Agile Team uses modified Fibonacci sequence of 1, 2, 3, 5, 8, 13, 20, 40 and 100 for estimation. The Fibonacci sequence prevents estimates from being too close to one another.
Benefits of using Fibonacci Scale:
- Increases the accuracy of estimates
- Establishes a scale for comparing story point complexity
- Whole team is involved – Each member gives a different perspective that helps to present a more accurate and realistic estimation of the work required to complete a user story.
Dot Voting
This technique is not used for estimation but could be used as a decision making or prioritisation technique. After the team has used estimation techniques to size the stories, the Product owner or product management team can prioritise the user stories to be taken up.
- Gather the team and showcase the epics or user stories to be prioritised on the physical / digital wall
- Provide 4-5 votes based on the total number of user stories or epics chosen to be prioritised. Roughly 20-25% of the total number of user stories
- Start the session by setting expectations of the event
- Each Participant is expected to vote on the criteria
- Team places their dots or votes on the user stories they believe are of higher priority.
- The process continues until all dots are used. Finally, the stories with the most dots are considered as high priority.
Analogy
In this agile estimation technique the user stories are not compared against a single user story / base story. Take a story estimate against an assortment of those that have been estimated. This estimation technique is also called triangulation.
For example if a user story is estimated of size 5 story points check to see if this is bigger that then the user story which is estimated at 3 story points and little smaller than story estimated at eight story points.
T shirt size
T shirt sizing is one of the common agile estimation techniques. Relative estimations are alternative to numerical estimation techniques. Unlike numbers, relative estimating allows team members to think in multiple dimensions—numbers are often associated with time, but t-shirt sizes can represent more complex ideas, including time, effort, and complexity.
To use t-shirt sizing effectively as one of the agile estimation techniques in Scrum it’s important to establish up front what each t-shirt size represents and where team members should clarify relative sizing.
Steps to use T-shirt sizing for estimates
- Decide on the sizes that the team can use (extra small, Small, Medium, Large, extra Large, etc.)
- Team should be aligned on what each size represents
- Assign t-shirt size to each Epic/Feature
- Track t-shirt size using work management tool like Aha
- Concept of base story can be used – please refer ‘Planning Poker” to understand how base story is decided by the team
Bucket System
This is another technique based on relative estimation. Used mainly when you have a large product backlog to estimate. The principles of estimation are the same as above. The user stories of the product backlog are given to groups The steps are mentioned below.
Prepare the backlog of items to be estimated. Enough information needed for estimation should be included in the user stories
- Decide on the size of the bucket. Explain to the group what each bucket is. The size of the bucket can follow a fibonacci series of 1,2 3,5, 8…
- Finalise the base story and its estimated size . Place it on the digital / physical wall.
- Pick a user story and spend a minute or two discussing the requirement. Check with all participants of the group which bucket this gets into. Identify the bucket relative to the base story and capture under the right sized Continue with another user story in the same way, reach a consensus , place the item in the appropriate bucket.
- if the team feels any user story doesn’t fit under previously placed bucket they may place in a different one
- Form groups and divide the user stories equally among all the members participating in the estimation.
- Every group reads the user stories on their own and places it under the appropriate bucket without discussing it with other groups
- Once all the items are placed under buckets, then all participants quietly review the user stories and ensure that they are placed rightly. If someone finds that an item is not placed in the right bucket, then the team can quickly discuss it and reach a consensus.
Affinity estimation
This technique also follows the concept of relative estimation. As the word Affinity suggests “close similarity to”. This technique is used when we have a large number of work items to be estimated and want it to be quicker. Whatever be the estimation technique used, focus must be around conversations, discussions about the work items Affinity estimation can be used with either fibonacci series or with T shirt size.
Steps to use Affinity estimation:
- Create columns on the whiteboard or in Miro with different T shirt sizes where each column represents a T shirt size
- Start by estimating the work items using T shirt and place the work items under relevant columns
- While placing work items in the right column we compare with the existing estimated work items to identify what size it belongs
- Place the work item in the column if it is same size as the one on the board
- Continue estimating the work items in similar way by comparing it with the others
- If the estimated work items have to be moved to different columns in comparison to the newly added work items discuss with the product manager around functionality , implementation if any for clarity
What Makes the Estimation of Agile Projects Challenging?
Chaos in the world brings uneasiness, but it also allows the opportunity for creativity and growth. – by Tom Barrett
Estimating in the VUCA (Volatile, Uncertain, Complex, Ambiguous) world can be very challenging. The current Agile project estimation techniques used in Agile ways of working are more reliable as forecasting, predictions are based on data driven insights which include all levels of uncertainty and complexity. Let’s delve into some of the common factors that makes estimation of agile projects challenging:
- Carrying the baggage of traditional planning where estimation is done based on work breakdown
- Lack of understanding the concepts of relative estimation
- Lack of adequate information in user stories leading to anomalies and investment of time by Product owner to enrich the stories
- Continuous emergence of changes on the functionalities leading to variability
- Lack of technical and domain knowledge resulting in identifying the effort needed to complete the requirement
- Inter and intra dependencies among teams
- Newly formed teams who don’t have synergies among themselves and work in silos within the team
Why do teams estimate in Agile?
In Agile estimation techniques, estimation is relative which means one user story is compared with another while figuring out the size of the user story. Relative estimation is natural for humans to estimate. Absolute estimation is done in isolation without comparing with another item. The estimation unit is usually in hours or days. Listed below are a few of the reasons why agile teams estimate the work in story points rather than days
- Understand the progress of work – Total story points completed per iteration is velocity of the agile team. Agile teams use velocity to understand progress of work
- Budgeting & Forecasting – Size of the backlog estimated in story points and the team’s average velocity helps the management to estimate project completion date or agile cost estimation
- Measure outcome over output – Completion of work in story points termed as velocity indicates the portion of the product backlog delivered in terms of functionality as opposed to traditional status of the progress in percent which talks about work completed across various phases like design , development, testing etc
- It is no longer boring – Agile teams actively take part in estimating and making commitments to work. Individuals are freed from task progress updates and micro management of their work resulting in increase in productivity levels
- Collective knowledge & consensus – Estimation by the agile teams increases shared understanding of the solution.
- Inclusive – Participation of business stakeholders, SME’s, product owners during agile estimation sessions improves decision making around the requirements.
- Courageous & out-of-the-box thinking – Risk identification and management is aggressive as Agile estimation techniques employed encourage exploring and brainstorming of user stories
Do’s and Don’ts of Agile Estimations
Peter Drucker reminded us all that ‘What gets measured gets managed.
As mentioned above there will always be some challenges during estimation. Some of the factors for challenges are stated above. To make estimation easier, smoother and more participative lets focus on some do’s and don’ts.
Best practices on improving agile estimation:
- Sensitise agile teams, and all the other participants on importance of Agile estimation
- Provide training to agile teams on various Agile estimation techniques and ensure on job training on their use cases
- Get buy in from leadership on using story points to measure size of product backlog
- Onboard leadership and the agile teams on importance of predictability
- Encourage agile teams to use velocity as a measure of progress rather than productivity of teams
- Identify a base user story and agree upon it to be used a reference while estimating new user stories
- Estimate epics and user stories in Sprint 0 at a very high level with help of T shirt sizing technique and as the details on user stories emerge using Planning poker technique.
- When a requirement / user stories have areas which are unclear or grey encourage teams to slice user stories into analysis tasks to bring in clarity before getting into implementation of a user story
- Timebox the event
- Set aside some time to discuss user story
- Use a timer while estimating
- Do not influence estimators on size of story
- If minimum & maximum estimates are identified the maximum value becomes size of the story
- Do not average estimates to cut discussions short
- People lacking knowledge of user story could opt out of estimation
- Avoid converting ideal days to story points
- Recalibrate base story
- Expert opinion from SMEs on requirements brings more clarity. Teams must consult with them to get better estimates on user stories
- Incorporate lessons on estimations from previous sprint retrospectives and reviews. Introspect why certain work items or requirements took longer or lesser than expected. Take the learnings to make estimates more accurate
- Conduct workshops on User story slicing. Whenever the user stories get harder to estimate slice the user stories into smaller user stores and to a level where they become estimable
- Enrich the user stories with adequate information in the form of wire frames, acceptance criteria, reference diagrams to bring clarity and avoid inaccurate estimations
- Allocate time every sprint to Backlog refinement. The user stories should be clarified by Product owner and SMEs to help team understand the requirement and provide estimates
How consulting companies like Benzne will help agile estimations in organisation?
At Benzne, our focus is primarily to address the business bottlenecks. In our discussion with our client counterparts, following has been the areas of concern where we identified implementing the agile estimation techniques could be helpful –
- Business Continuity Impacts i.e. when delivery dates are crucial for business sustainability or else
- SLA could be breached
- An important market event will be missed
- Potential opportunities to retain or acquire new customers
- Impact on heat map
- Helping in forecasting roadmap to their end customers
- Mismatch in billability
- Lack of maturity in terms of commitment & delivery
- Missing metrics to support business health
- Team level Commitments
- Visibility of progress
- Predictability of work
- Managing priorities
- Planning for solutions
- Facilitating systematic rolling wave events
- Planning Interval (PI planning)
- Season based governance
- Product discovery forecast
- Product backlog management
- Planning releases & milestones
- Reducing cycle & lead time
Our ways of delivery includes –
- Understanding of current ways of working & identifying gaps
- Landscaping the overall scope
- Focused workshops
- Continuous coaching support for enablement
- Scaling initiatives to expand impact
FAQs
- What is the tool used for effort estimation in Agile?Effort estimation is part of the story point . When estimating a story point 3 areas have to be considered. Effort taken by the entire team to complete the user story,complexity of the work Uncertainty in the story. We have listed the various tools and techniques for effort estimation in Agile in the blog.
- What is relative sizing?Agile estimation techniques are relative. In relative sizing we compare size of one user story relative to another user story
- What are the various agile estimation techniques?Various agile estimation techniques are :
Three point estimate
Planning Poker
Fibonacci Series Sequence For Story Point Estimation
Dot Voting
Analogy
T-Shirt Size
Bucket System
Affinity System
