What are some common estimation techniques and tools for agile and waterfall user stories? (2024)

Agile: Common techniques include Story Points, Planning Poker, and T-shirt Sizing. Tools like JIRA and Trello help track and manage estimates.Waterfall: Techniques often involve detailed Work Breakdown Structures (WBS) and expert judgment. Tools such as Microsoft Project or Primavera support detailed scheduling and resource allocation. Both approaches benefit from regular review and adjustment of estimates based on project progress.

(edited)

Agree with the T-Shirt size approach, as it stays true to the concept of relative sizing. While using the Fibonacci sequence, there is a tendency to confuse and co-relate the numerical value of the sequence with the "absolute hours" which defeats the purpose of relative estimation. T-shirt sizing on the other hand, keeps it categorical and relative from an estimation stand point !

The simplest or easiest technique is to use the T shirt sizing technique. The team gets to easily categorize requirements into S,M,L,XL etc. based on the complexity and size of work to be completed.Another method is to use story point estimation,where stories are sized using the Fibonacci series of numbers.While this is not meant to be accurate they help in quantifying and planning projects better than T shirt sizing.Ultimately, most of these techniques are relative estimation based.You need to have a baseline requirement estimation against which you compare other requirements either using T shirt sizing or using story point estimation.Also, estimations are meant to be dynamic and become better as the project matures.

I usually use a story to explain this to my colleagues. Relative sizing is like a car which need to travel 200 km in a road, from point A to point B. The time to cover from point A to B will be relative. Why?Because it will depend on the status of the road, the status of the traffic, the status of the car, the number of curves that the road has, and many other things. Despite this car can go maximum 200km/h (Capacity, an absolute number), the road has a limit of 100km/h (probable Velocity), and then the curves will make me reduce the velocity between 60km/h to 80km/h (or not that fast, another relative measure).In conclusion, team agrees the relative size based on the complexity of the work and the experience of the team.

widely adapted technique: Whom: New teams, large backlogsWhy: Helps your team get a rough estimate of a task quickly, enables good team collaborationScale: XS,S,M,L,XL,XXLHow: a. the Product Owner reads out a story and asks team members to estimate how much effort it will takeb. You express this with a scale of t-shirt sizesc. For unbiased T-Shirt Sizing, teams can use a blind estimation processd. You privately pick your estimate to prevent influencing others. Once everyone has made their choice, reveal your estimates simultaneouslye. This approach fosters diversity of thought and helps prevent the risk of groupthink or conformity.

Team: Established teams, Prioritized backlogs, Large-stage estimation Why: Encourage conversations & Sprint poker is perfect for teams with specific User stories the team wants to discuss in detail Scale: 1,2,3,5,8,13,20,40How to do: a. Poker card will be given which has value (1,2,3,5,8,13,20,40)b. PO reads out the user story and ask the team members to show their card c. if all the cards are same (for e.g., 8),then fix it against the story pointd.If the numbers are different, all the developers discuss to consensus.e.After the discussion happens, again they must show the cards, until the numbers come in common f.Till the numbers comes same, then put the numbers against that Story point.

As an agile coach, I believe it is important to team planning poker along with other different ways to estimate. We also have to train on INVEST criteria for creating bulletproof user stories. You can't have one without the other. Planning poker has lost as lot of favor as Agile has become more commonplace in knowledge with 20+ years of existence. Many companies don't allow for the time for these activities as well as Scrum Masters and Coaches. I always suggest it and provide the team with planningpoker.com as a resource. At the end of the day, the tooling uses points to run data reports, so the Scrum Master needs to take the estimates and plug them into the system.

Planning Poker adds a touch of fun to the estimation process, all the while promoting teamwork and communication. The adaptability of this tool makes it extremely valuable in Agile settings, as it encourages collective ownership of project estimates.

Team members use cards with numbers representing story points to vote on the complexity of a user story.Facilitates team discussion and convergence on a consensus estimate.

Planning poker is a consensus-based estimation technique where team members individually estimate the size of user stories using planning poker cards (numbered cards representing story points) and then discuss their estimates to reach a collective agreement.

what: Measurement unit to determine effort required to complete product backlog item Why: * Allows team make longer term predictions*Coordinate dependencies and work *Align priorities and decide on high-value tasks*Through discussion and engagement, it enables shared understandingWhen: * Product backlog refinement * Sprint planningYou can estimate the Story point either Relative or Absolute. Story point is used in Relative estimation

One thing that will always be true about story points is that they are subjective. As I mentioned previously in this collaborative article, story points are required for metrics if you are going to use Jira. If you want to optimize your reports and dashboards with real-time and AI reporting, the CSM will require them. Always use the INVEST Criteria when creating user stories. Always consider the risks and dependencies when estimating. The higher the risk/dependencies, the higher the story points.

Story points provide a complex and Agile-focused method for estimating and handling the size of user stories. Teams can enhance their ability to adapt to the iterative nature of Agile development by prioritizing complexity and effort over strict timeframes. This approach promotes flexibility and continuous improvement.

I frequently use story points to effectively estimate relative effort requirement for a user story. Unlike any absolute scale that can prove to be hard to benchmark against varying complexity of the user stories, story points have the flexibility to estimate efforts from implementation perspective.Story points also gives a project manager the opportunity to effectively build a trust based system with the devs that can remain consistent throughout the project, even if the nature of the project changes with time or client inputs.I have used story points successfully in the past to accurately plan release cycles, thus reducing the risk of delays or cost overrun in the project.

Story Point is a unit of measure used in Agile to quantify the size, effort, and complexity of user stories. Story points are typically assigned based on relative sizing and represent the overall effort required to complete a user story.

Ideal Hours involves estimating the effort required to complete user stories in terms of ideal working hours. Team members estimate the number of hours they would need to complete each user story under ideal conditions, without considering interruptions or external factors.

As a PMO and APMO Practice Director, I will say this is more in the PM wheelhouse. The formula is as follows: Ideal Hours = (Estimated Effort) / (Productivity Rate). Estimated effort is the amount of time that it is estimated to take to complete a task, activity, or project. This can be estimated using a variety of techniques, such as expert judgment, historical data, or analogy.Productivity rate is the average amount of work that can be completed in a given period of time. This can be estimated by tracking the time that team members spend on different tasks and activities, and then calculating the average amount of work that they complete in a given period of time. One might be able to look into velocity or prior work history.

A technique used primarily in waterfall or traditional project management methodologies to estimate the size and effort of user stories based on predefined use case scenarios and associated factors such as complexity, inputs, outputs, and transactions.

Oftmals finden Planning Poker Sessions heute remote statt. Zahlreiche Tools, die die Verwaltung von User Stories erlauben, bringen mittlerweile auch Möglichkeiten mit, diese direkt in der Planning-Poker Variante zu schätzen. Daneben gibt es zahlreiche kostenfreie Werkzeuge, die ein Planning Poker remote unterstützen. Teilweise sind diese Open Source und können selbst gehostet werden.

Translated

As a professional using Jira/Confluence for over 20 years, as well as Asana, Trello, Smart Sheets, Azure Dev Ops, and more, I always go back to Jira. Jira is more malleable with data as well as portability. I can input my data into Jira and get awesome real-time dashboards for my clients for transparency and it helps uncover dysfunctions within teams as an agile coach. A skilled agile professional can look at the data and ask the right questions to uncover previously unseen information about a project. I can also pull custom and formatted reports rapidly when someone pings me. When configured properly by a trained Jira admin/user, Jira can really turn Agile pros into reliable superstars that can save the company loads of money.

Various estimation tools and software platforms are available to support Agile and waterfall estimation processes, including digital planning poker apps, project management software with built-in estimation features, and specialized Agile estimation tools that offer functionalities such as backlog grooming, velocity tracking, and reporting.

Common estimation techniques for Agile user stories include story points and planning poker, while Waterfall relies on detailed task-based estimates. In wind projects, Agile may estimate turbine installation using story points, while Waterfall might detail each task. Energy storage Agile estimates battery development with story points, while Waterfall breaks down tasks like material sourcing. Grid connection Agile may use story points for flexible system integration, while Waterfall might detail each step in the integration process. For offshore wind, Agile might estimate foundation design with story points, while Waterfall details individual engineering tasks. Tools like Jira aid in Agile, while Waterfall often uses Microsoft Project.

For Agile user stories, common estimation techniques include:Story Points: Assigning a relative complexity score to user stories, often using Fibonacci numbers, to represent effort required.Planning Poker: Team members anonymously vote on story point estimates, discussing until a consensus is reached.For Waterfall user stories:Expert Judgment: Experienced team members or subject matter experts provide estimates based on their expertise.Analogous Estimation: Using past similar projects as a basis for estimating the current one.