Search

Top 5 Scrum Estimation Techniques- Find Your Best Fit

Estimation, the very word in itself seems quite heavy, and it does feel substantial when you are asked to estimate unfamiliar items to some degree. One of the key advantages of adopting Agile is the capability of the team to estimate work effectually. Earlier when the teams were on waterfall, they used bottom up approach with the smallest tasks at the bottom, in order to determine the cost of each feature. On the contrary, Agile uses two estimation techniques, such as Top-Down Estimation and Relative Sizing, since we are not concerned about the detail of the tasks. Instead, we are much more interested in swift estimates of higher-level features, or even epics.What is Estimation?“Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.” – Wiki.As a part of the Scrum process, the development team sits together in the planning session, pulls out the items as per priority from the backlog and associates an estimate to the PBI (Product backlog item). The size of the PBI is projected in terms of User Story Points.I remember when my teams used to be quite first-hand at the concept of estimating the efforts, in the initial days, I could sense the uneasiness and question mark on their faces, it is the hardest part if implemented in true sense. But once they get used to it, they regain confidence.Estimation is necessary for any planning practice;Why to estimate?In my last session on estimate, I asked, why do we estimate and the answers I received were-To get people liable for their workTo predict the finish lineTo fill up the sprint with workTo measure teams’ progress we do estimationAnd lastly, because that’s what we do in estimation in Agile, right? (Partially true)But in true sense, estimates are required to plan work and time. It even helps the team to measure success in terms of numbers. Surprised! Yes they do project success, through velocity, sustained velocity figures, up rise in the numbers. Estimates can be turned into release plans too!! Even they help you make weighty decisions.“Estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, it’s almost never an estimating problem, it’s a shared understanding problem” - MIKE COTTMEYERHow to Estimate?Estimating work items for new teams gets quite difficult as the teams are unfamiliar with the requirements and require solution but over the time, as team members get used to the product, they develop a progressively precise sense of how they’re going to approach stories and how much effort each user story will take to complete.As human beings, we are typically good at relatively estimating the items, e.g. we cannot predict at first instance if the Earth is heavier than Mercury, because heaviness is dependent on density which is not a visual thing to determine but we can confidently say that the circumference of Earth is bigger than that of Mercury as size is can be determined easily by visualization. Hence, we can relatively estimate the size of earth in comparison to the Mercury just by looking at it. Let’s consider the image below which shows how the product can be estimated. Teams across the world use a variety of methods to estimate their work. You just have to find the right way of doing it, or rather the way which is most suitable for your team’s need. There is no fixed rule for estimation and luckily we live in a planet where options are not scarce and this applies to estimation as well!Types of estimation techniques:Accordingly, I will now be discussing some of the methods which I have personally used with my teams. Starting off with the one which is being widely used across the globe:1) Planning PokerPlanning Poker is an Agile estimating and planning technique that is based on an agreement from the team on the points being assigned to the PBI. It makes sure that everyone participates and that every individual in the team shares his/her opinion.To start with, each team member is given a set of cards with numbers on them. The numbers are usually in the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21. The product owner reads out the story, after which, everybody in the team is asked to hold up the card showing the level of effort that they believe this story holds. Once all the votes are in, the team members with the lowest and highest estimates explain why they choose their numbers. The team then re-estimates as per the new perceptions discussed. Once the agreement has been reached that score is recorded with the story to which it relates, the team is good to proceed.2) T-Shirt SizesThis is a seamless technique for estimating a huge backlog of relative large items. T-shirt sizing is based on the concept of binning- a technique for accurately grouping together items of similar size. The bins are typically allocated labels matching to those commonly used with T-shirt sizes: extra small, small, medium, large, extra-large, etc.The primary advantage to t-shirt sizes is the ease of getting started. T-shirt sizes can be a great way of becoming familiar to relative estimating. So, you can start with it if your team finds that easier.3) The Bucket SystemMuch quicker than planning poker is the Bucket System. This system is a decent substitute when estimating a large number of items with a large group of participants quickly. Different buckets are created with values: 0,1,2,3,4,5,8,13,20,30,50,100, 200. The stories need to be placed within these where the estimator finds them suitable. The group estimates the items by placing them in these “buckets”. Buckets are usually different sheets of brown paper where you can place the sticky note with the item. But you can also use actual baskets to limit discussion about already processed items.4) Large/Uncertain/SmallA very fast method of rough estimation is the Large/Uncertain/Small method. The team categorizes the items as per being Large/Uncertain/Small, starting with populating the extreme categories. Following which, the group can discuss the more intricate items. This is actually a generalization of the bucket system. The system is especially good to use in smaller groups with comparable items.5) Dot VotingWhen there is a relatively small set of items and you don’t want any complex techniques, you can opt for Dot Voting. This method has been coined from decision making and can be used for estimating. Each person gets a small number of stickers and can choose to vote for the individual items. More the dots, bigger is the size. This method is very simple and fast, it will work effectively to assess a small number of stories (up to 8-10).ConclusionThere are many techniques that the teams use globally to estimate their work, here we have discussed the top five but there is no consensus over which method is best. Each method has its own advantages and has been customized as per the team’s functioning pattern. Like there is no common medicine that applies to all ailments, in the same way, there is no single method that applies to all for estimating. A facilitator has to understand that estimation takes time to sink in with the teams and it should not be forced upon. Go for the one which best suits your team’s need and at the same time, can provide optimum results.Happy Estimating!
Rated 4.0/5 based on 2 customer reviews

Top 5 Scrum Estimation Techniques- Find Your Best Fit

221
Top 5 Scrum Estimation Techniques- Find Your Best Fit

Estimation, the very word in itself seems quite heavy, and it does feel substantial when you are asked to estimate unfamiliar items to some degree. One of the key advantages of adopting Agile is the capability of the team to estimate work effectually. Earlier when the teams were on waterfall, they used bottom up approach with the smallest tasks at the bottom, in order to determine the cost of each feature. On the contrary, Agile uses two estimation techniques, such as Top-Down Estimation and Relative Sizing, since we are not concerned about the detail of the tasks. Instead, we are much more interested in swift estimates of higher-level features, or even epics.

What is Estimation?

“Estimation (or estimating) is the process of finding an estimate, or approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.” – Wiki.


As a part of the Scrum process, the development team sits together in the planning session, pulls out the items as per priority from the backlog and associates an estimate to the PBI (Product backlog item). The size of the PBI is projected in terms of User Story Points.

I remember when my teams used to be quite first-hand at the concept of estimating the efforts, in the initial days, I could sense the uneasiness and question mark on their faces, it is the hardest part if implemented in true sense. But once they get used to it, they regain confidence.

Estimation is necessary for any planning practice;
What is EstimationWhy to estimate?

In my last session on estimate, I asked, why do we estimate and the answers I received were-

  • To get people liable for their work
  • To predict the finish line
  • To fill up the sprint with work
  • To measure teams’ progress we do estimation

And lastly, because that’s what we do in estimation in Agile, right? (Partially true)

But in true sense, estimates are required to plan work and time. It even helps the team to measure success in terms of numbers. Surprised! Yes they do project success, through velocity, sustained velocity figures, up rise in the numbers. Estimates can be turned into release plans too!! Even they help you make weighty decisions.

“Estimating isn’t about estimating at all. Estimating is about creating a shared understanding of the requirements, and a shared understanding of the solution. When teams have problems estimating, it’s almost never an estimating problem, it’s a shared understanding problem” - MIKE COTTMEYER
Why to estimateHow to Estimate?

Estimating work items for new teams gets quite difficult as the teams are unfamiliar with the requirements and require solution but over the time, as team members get used to the product, they develop a progressively precise sense of how they’re going to approach stories and how much effort each user story will take to complete.

As human beings, we are typically good at relatively estimating the items, e.g. we cannot predict at first instance if the Earth is heavier than Mercury, because heaviness is dependent on density which is not a visual thing to determine but we can confidently say that the circumference of Earth is bigger than that of Mercury as size is can be determined easily by visualization. Hence, we can relatively estimate the size of earth in comparison to the Mercury just by looking at it. Let’s consider the image below which shows how the product can be estimated.
 How to EstimateTeams across the world use a variety of methods to estimate their work. You just have to find the right way of doing it, or rather the way which is most suitable for your team’s need. There is no fixed rule for estimation and luckily we live in a planet where options are not scarce and this applies to estimation as well!

Types of estimation techniques:

Accordingly, I will now be discussing some of the methods which I have personally used with my teams. Starting off with the one which is being widely used across the globe:

1) Planning Poker
 Planning PokerPlanning Poker is an Agile estimating and planning technique that is based on an agreement from the team on the points being assigned to the PBI. It makes sure that everyone participates and that every individual in the team shares his/her opinion.

To start with, each team member is given a set of cards with numbers on them. The numbers are usually in the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21. The product owner reads out the story, after which, everybody in the team is asked to hold up the card showing the level of effort that they believe this story holds. Once all the votes are in, the team members with the lowest and highest estimates explain why they choose their numbers. The team then re-estimates as per the new perceptions discussed. Once the agreement has been reached that score is recorded with the story to which it relates, the team is good to proceed.

2) T-Shirt Sizes
 T-Shirt SizesThis is a seamless technique for estimating a huge backlog of relative large items. T-shirt sizing is based on the concept of binning- a technique for accurately grouping together items of similar size. The bins are typically allocated labels matching to those commonly used with T-shirt sizes: extra small, small, medium, large, extra-large, etc.

The primary advantage to t-shirt sizes is the ease of getting started. T-shirt sizes can be a great way of becoming familiar to relative estimating. So, you can start with it if your team finds that easier.

3) The Bucket System

Much quicker than planning poker is the Bucket System. This system is a decent substitute when estimating a large number of items with a large group of participants quickly. Different buckets are created with values: 0,1,2,3,4,5,8,13,20,30,50,100, 200. The stories need to be placed within these where the estimator finds them suitable. The group estimates the items by placing them in these “buckets”. Buckets are usually different sheets of brown paper where you can place the sticky note with the item. But you can also use actual baskets to limit discussion about already processed items.

4) Large/Uncertain/Small

A very fast method of rough estimation is the Large/Uncertain/Small method. The team categorizes the items as per being Large/Uncertain/Small, starting with populating the extreme categories. Following which, the group can discuss the more intricate items. This is actually a generalization of the bucket system. The system is especially good to use in smaller groups with comparable items.

5) Dot Voting

When there is a relatively small set of items and you don’t want any complex techniques, you can opt for Dot Voting. This method has been coined from decision making and can be used for estimating. Each person gets a small number of stickers and can choose to vote for the individual items. More the dots, bigger is the size. This method is very simple and fast, it will work effectively to assess a small number of stories (up to 8-10).
Dot VotingConclusion

There are many techniques that the teams use globally to estimate their work, here we have discussed the top five but there is no consensus over which method is best. Each method has its own advantages and has been customized as per the team’s functioning pattern. Like there is no common medicine that applies to all ailments, in the same way, there is no single method that applies to all for estimating. A facilitator has to understand that estimation takes time to sink in with the teams and it should not be forced upon. Go for the one which best suits your team’s need and at the same time, can provide optimum results.

Happy Estimating!

Deepti

Deepti Sinha

Blog Author

Deepti is an Agile Coach by profession and Freelance Trainer with over 11 years of industry experience working primarily with healthcare & finance clients in delivering business. She has played a wide variety of roles in the graph of her career, whether it be, management, operations or quality. She likes reading fiction, management and loves to write her experiences. Her colleagues mostly describe her as very detail oriented person with a knack of creativity and imagination. And yes, she loves feedback more than her coffee!!

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Benefits of Implementing Agile Practices for Infrastructure Operations Support Teams

Agile methodologies have become mainstream and more than 90% of the organizations had indicated that they are practising Agile in some form or the other (Version One, State of Agile Survey, 2016). In this post, I will highlight how a specific Agile methodology is used in the infrastructure space to manage routine operations work.  In the infrastructure domain, there are not many organizations which are using Agile as it is not easy to implement the scaled Agile framework (Scrum) as the nature of work is more from the operational perspective as compared to the product development space where the focus is on knowledge work. However, in large enterprise organizations (> 5000 members), if an organization has to become agile, all the divisions will sooner or later need to focus on Agile. The organization does not derive much benefit if only one division in the organization is focused on Agile and all the other divisions are not being agile. Hence, initially as part of the Agile transformation, the product development division adopts Agile and subsequently, other support divisions also focus on exploring Agile and how to implement Agile for their activities.  With this background context, I would like to explain how the Infrastructure teams which are engaged in operational activities focus on implementing Agile in their projects/activities. Taking the specific example of a Unix Server Support team which is offering support for L1, L2 and L3 activities (L1, L2 and L3 – different and increasingly varying and higher levels of support where the team focuses on providing support to the customer, e.g. – L1 – call center support, L2 – Basic configuration and minor changes, L3 – Deep Dive and resolution of problems). Generally, the Infrastructure teams follow the ITIL Best Practices to ensure that their services are providing optimal support to the customer (24*7 support – also enabling follow the sun approach). In this case, when we are implementing Agile practices for these teams, I have observed that Kanban practices and a good Kanban framework help the team integrate ITIL with Agile practices.  These teams are focused on operations work which is routine and is undertaken daily through the implementation of a help desk support system (Service Now, Impulse, Jump, Remedy and other tools) utilizing tickets that are raised by people and non – humans (computer programs).  The tickets are raised automatically by computer programs (incidents), raised by humans (mostly requests), problems (raised by humans), change requests/ctasks (change tasks) by humans. Hence, ITIL implementation provides a good focus on the key areas – Incident Management, Problem Management, Change Management, Help Desk and related areas. In such a scenario, the implementation of Kanban helps to integrate ITIL and Agile and the team does not feel the extra burden of the Agile implementation. Kanban easily dovetails with the existing ITIL framework and the team is able to implement both Kanban and ITIL at the same time. This ensures that the team is meeting the organizational requirements and at the same time, the team is also able to implement Agile as per the requirements.  The routine operational work of these teams is considered as one big project focused on delivering operational support and meeting the service level agreements for the customer. Kanban is basically a framework for managing the process flow and change in a visual manner. It starts with the as-is state and slowly builds on incremental improvements to improve the process over a period of time. Hence, it becomes easier to start with the already existing ITIL processes which the teams are already following in their day to day work. The Kanban system focuses on visualizing the process flow and identifying the bottlenecks in the process and how they could be eliminated so that the process becomes faster from concept to cash. In this case, it derives the basic inspiration from Lean principles which are also focused on identifying and maximizing value, while minimizing waste at the same time.  The focus on implementing Kanban frameworks for the Operations team in the Infrastructure domain leads to the following benefits–  The team can manage its process flow with the already existing systems in place (e.g. lean, ITIL and other process models/frameworks).  Workload Management, Capacity Adaptation, and Capability/Competency Improvement in the teams. It is easier for the team to implement Agile practices as Kanban focuses on starting with the existing processes instead of making any drastic changes in the basic process.  The team is able to visualize the basic work through the technique of value stream mapping (VSM) and it is able to eliminate bottlenecks using the Theory of Constraints (ToC).  The team is able to identify the core values and focus on how to enhance customer delight.  Implementing Agile practices leads to improved team motivation and team morale.  Focus on working at a sustainable pace instead of working in death march projects which leads to quicker burnout and increased attrition.  It helps the team to visualize the workflows which enables the team to focus on out-of-the-box thinking and innovative techniques to improve lead times of their processes.  Simple metrics like – lead time, cumulative flow diagrams and Yamazumi charts help the team to focus on their processes and check how they could fine tune their processes further.  Lessons learnt as part of the Kanban meetings and workshops enable the team to focus on continuous improvement.  The focus on Kanban practices enables the team to set up a robust ecosystem in the organization that engenders continuous learning and enables the organization to build the skill level of its employees.  Assimilation of new processes by the team through design thinking and other techniques for providing operational support helps the team to improve customer satisfaction. Thus, we can observe that the choice of selecting Kanban as an Agile implementation methodology for the Operations Support Teams in the Infrastructure domain is a prudent option as it helps the team to continue following its existing processes and at the same time also implement Agile practices in their projects with minimal conflicts. In future posts, I will highlight how we could go about implementing Kanban and Agile practices in the Infrastructure Operations Support teams, providing support to the product development teams in the organization.   
Rated 4.0/5 based on 20 customer reviews
1055
Benefits of Implementing Agile Practices for Infra...

Agile methodologies have become mainstream and mor... Read More

Scrum Master and Product Owner: Understanding the differences

 Agile methodology imparts the easy and convenient path to work. Scrum is one of the famous Agile methodologies. Agile methodologies consists of 4 main roles, viz. Product Owner, Scrum Master, Scrum team and Stakeholder. Each role has its share of responsibilities. These roles are all about commitment. Scrum master and the Product owner are two vital roles in the Scrum Software Development Methodology. Since they both are working on different areas of the project, they are indispensable for the project. Scrum Master is a mediator between the Product owner and the Development Team.       Product Owner vs Scrum Master- Though the Product Owner and the Scrum master vary in their roles, they complement each other. Scrum master should support the product Owner in every step possible. There should be an amicable relationship between the Product owner and the Scrum master. Disputes may happen between them if the roles are not clarified. Let us have a look at the differences in roles between the product owner and the scrum master. The Scrum Master concentrates on the project success, by assisting the product owner and the team in using the right process for creating a successful target and establishing the Agile principles.    Scrum Master Skills (SM): SM creates a friendly environment for the team for Agile development. SM improves the quality of the product. Certified Scrum Master Certification, adds advantage to become effective. SM protects his team from any kind of distraction and allows them to stay tuned. SM helps product owner to maximize ROI (return on investment) to meet the objectives. SM removes disputes between the product owner and the development team. SM encourages the team to meet the project deadline. SM acts like a coach for a team to perform better. A good Scrum Master should possess the skills like project management, engineering, designing, testing background and disciplines. SM provides continuous guidance to teams   Duties of Scrum Master: SM facilitates team for better vision and always tries to improve the efficiency of the teams. SM manages Scrum processes in Agile methodology. SM removes impediments for the Scrum team. SM arranges daily quick stand-up meetings to ensure proper use of processes. SM helps product owner to prepare good product backlog and sets it for the next sprint. Conducting retrospective meetings. SM organizes and facilitates the sprint planning meeting. The Product Owner’s responsibility is to focus on the product success, to build a product which works better for the users and the customers and to create a product which meets business requirements. The product owner can interact with the users and customers, stakeholders, the development team and the scrum master.   Product Owner Skills (PO): PO should have an idea about the business value of the product and the customers’ demands. Certified Scrum Product Owner Certification (CSPO) will be beneficial for the sales team. The development team consults PO, so he should always be available for them to implement the features correctly. PO should understand the program from the end-user point of view. Marketing is discussed on the sales level in most of the Organizations. So it is the PO’s duty to guide the marketing persons to achieve the goals successfully. PO is responsible for the product and the ways to flourish a business. PO has to focus for the proper production and ROI as well. PO should be able to solve the problems, completing trade-off analysis and making decisions about business deliverables. After CSPO course, PO can work with the project managers and the technical leads to prioritize the scope for product development. Sometimes PO and the Customers are same, sometimes Customers are thousands or millions of people.   Duties of the Product Owner: PO has to attend the daily sprint planning meetings. PO prioritizes the product features, so the development team can clearly understand them. PO decides the deadlines for the project. PO determines the release date and contents. PO manages and creates the product backlog for implementation, which is nothing but the prioritized backlog of user stories. PO defines user stories to the development team. Spending some time to prioritize the user stories with few team members. One can enhance his/her knowledge in many directions and beyond boundaries, after undergoing the Certified Scrum Product Owner (CSPO) training.
Rated 4.0/5 based on 1 customer reviews
2590
Scrum Master and Product Owner: Understanding the ...

 Agile methodology imparts the easy and convenien... Read More

4 Features Of SAFe

Agile is a very popular project management methodology that is being used by companies all over the world. The general method of implementing Agile methodology was to create small teams and let them divided the large task into smaller components and start working on it. This approach works well at the enterprise level. Over the years, many experts were closely watching and analyzing these techniques. They made a list of what are the practices that worked and what didn’t. The experts developed various frameworks to suit the various needs of organisations. This is what led to the invention of the scaled Agile framework. This framework is slowly gaining popularity and companies are taking notice of its pros and cons. It is the management team’s responsibility to choose the best practice in order to have a clear idea about the ROI (Return on Investment) and how improvements can be made in the processes. Therefore, once a company decides to adopt Agile techniques, a general option is not available. There are various methodologies and frameworks. The company needs to identify the one that suits their work culture and mode of business the best and adopts it. The framework should be selected after thoroughly weighing the pros and cons. The Scaled Agile Framework was invented by Dean Leffinwell and has the following main features: 1) Easy to implement – Scaled Agile Framework (SAFe) has a complex structure and is basically used by large companies when they want to adopt the Agile framework. It is basically the go-to option for large software teams that are inter-dependent. An organization can easily switch to SAFe by following the tons of articles, videos, and tutorials online. The only problem a few senior management officials tend to face is that they implement all the components of SAFe without truly understanding its actual usage. This tends to add more complexity to the processes. 2) Different levels of SAFe – VersionOne helps you implement SAFe in the following ways • Team Level: It is necessary to keep each member of the team motivated and allow them to work with ease. The most important component of an Agile system is the team members following it. VersionOne provides a particular system through which multiple teams can work together with ease. This approach can be applied to the teams working on ScrumXP or Kanban. Through VersionOne, the teams can collaborate smoothly and deliver the software with ease. • Value Stream Level: This is one of the optional levels and adopted by companies only when they have huge, complex systems that contains multiple Agile release trains. Using SAFe’s Value Stream level, the teams can plan, track, and deliver the most complex systems with ease. • Portfolio Level: This is considered as the basic level where all the planning and strategies are discussed. In this level, the decisions for value stream level funding are made. • Program Level: At this level, SAFe focusses on how the Agile teams are integrated in order to create better customer value. To do this, VersionOne enables you to track your program increments and also coordinate all the activities of your release train. 3) Concept of release trains – A release team is a team consisting of a large group of employees usually consisting of 50-125 of them. It can be compared to an actual train as it runs on a pre-fixed schedule. This schedule can be flexible though and the timings can be decided by the members of the team. It is advised that the team members working on a particular release train should be completely focused on that particular train and not worry about the reporting structure. A release train usually consists of a long-term which will have many teams and projects within it. 4) Various certifications – There are six scaled Agile framework certifications available based on your role in the SAFe team. They are: 1) SAFe Program Consultant Certification (SPC4) – This certification is meant for Agile change agents and external consultants in order to help them adopt SAFe and launch Agile release trains. 2) SAFe Agilist (SA) – This is meant for executives, managers and Agile change agents so that they can easily adopt SAFe methodology. 3) SAFe Practitioner (SP) – It is meant for project managers, product managers, software developers and testers. It will help them easily adopt the framework on a team and program levels. 4) SAFe Program Consultant Trainer 4.0 (SPCT4) – This certification is suitable for Scaled Agile Gold Partners so as to enable them to train and certify SAFe program consultants and grow their community. 5) SAFe Product Manager/Product Owner (SPMPO) – It is meant for business owners, product owners, product managers, program managers, and business analysts. This certification will enable them to carry out better product development flow and scrum team delivery.
Rated 4.0/5 based on 20 customer reviews
4 Features Of SAFe

Agile is a very popular project management methodo... Read More