Estimating agile projects with multiple teams can be challenging, especially when each team has different skills, velocities, and dependencies. How can you ensure that your estimates are realistic, consistent, and aligned with the project goals and scope? In this article, we will explore some of the best practices and tools for agile estimation with multiple teams, such as:
Rather than assigning hours or days to each task or feature, use relative sizing methods such as story points, t-shirt sizes, or Fibonacci numbers to compare the complexity and effort of different items. This way, you can account for the uncertainty and variability of agile projects, and avoid anchoring or overcommitting. Relative sizing also allows you to normalize the estimates across different teams, by using a common scale and reference points.
Plan, Plan, Plan Keep numbers of steps per task small (<5) and replan orchestration as work proceeds. Complexity should be reduced to well established approaches in the domain as everything should be done in bite sized chunks (that anybody in the committed agile team(s) can do in the domain). Use consistent heuristics where possible. Remember an estimate is only an estimate. It is basically time to do something and may vary considerably. If elapsed time more than 6 standard deviations then the whole approach (especially dependencies) has failed and needs replanning. Heuristics are mental shortcuts that allow people to solve problems and make judgements quickly and efficiently. If a decision takes longer than a minute that is too long.
Combining T-shirt sizing with prioritization (High/Medium/Low) has proven to be effective in my project, specifically in a client onboarding application where I had to collaborate with multiple scrum teams.
Estimating with a range (eg 2 to 4 weeks) have helped in our project where developers are afraid of sizing inaccurate numbers, the range seemed to reduce this fear.
To make relative sizing work, you need to establish a common baseline for your estimates, such as a reference story or feature that all teams agree on. This will help you calibrate the estimates and ensure that they are comparable and consistent. You can also use historical data from previous projects or sprints to adjust the baseline and improve the accuracy of your estimates over time.
I think a good way to do this amongst a team is to use a method like ‘scrum poker’ where you have a list of tasks that lead to the completion of a set result made by a customer or client. The team sits together and gauges the value of a card against the difficulty of the task needing to be completed. Some will give a higher number due to inexperience or great understanding in the area or vice versa. This gets the team collaborating, provides insight into each task and allows a better look at what level of effort (as well as steps) the task sits at.
Instead of estimating the entire project upfront, plan in iterations or sprints, and estimate only the items that are ready for development. This will allow you to incorporate feedback, changes, and new information into your estimates, and reduce the risk of scope creep or rework. Planning in iterations also helps you track the progress and performance of each team, and adjust the estimates accordingly.
Yes, plan in iterations, and scan and refine the backlog in preparation for sprints. Otherwise you’re just guessing based on a lot of unknowns. One thing I’ve noticed is that if estimates are far off, it’s often because the people involved haven’t worked together as a team on similar projects enough.
I agree and also it is important to have the product back log refinement session prior to plan in iteration to ease and speed the task of estimation since the product backlog refinement will make sure that the stories are defined according to definition of ready and are tasked so it is easy to estimate. Use 20,30,50 rule of product back log refinement balance.
Estimating with multiple teams can be difficult, especially when they are distributed or remote. To facilitate the estimation process, you can use estimation tools that enable collaboration, communication, and transparency. For example, you can use online planning poker, affinity mapping, or bucket system tools to conduct interactive and anonymous estimation sessions with your teams. These tools can also help you visualize, analyze, and report the estimates, and identify any gaps or discrepancies.
Finally, you need to align the estimates with the project vision, scope, and goals, and communicate them clearly to all stakeholders. You can use techniques such as release planning, roadmap planning, or minimum viable product (MVP) planning to prioritize the features and tasks that deliver the most value and impact to the project. You can also use metrics such as velocity, burnup charts, or value stream maps to monitor and communicate the progress and outcomes of the project.
Estimating agile projects with multiple teams is not an exact science, but a collaborative and iterative process that requires constant learning and adaptation. By following these best practices and tools, you can improve your estimation skills and deliver successful agile projects with multiple teams.
In my experience, I would like to share some idea here on how to manage and estimate the agile projects among multiple teams for smooth flow. Regularly review and refine the estimates as the project progresses. As teams gain more insights and information during the project, they can adjust their estimates to reflect the actual progress and any changes in scope or requirements. Continuously monitor the progress of each team and the project as a whole. Agile estimation is an iterative process, and adjustments may be necessary as the project evolves. Regularly communicate and collaborate with the teams to ensure that the estimates remain accurate and reflect the current situation. Because Every estimation can not be correct at the beginning.
Every estimate is wrong, and you don't know by how much. The more precise you try to be with your estimates, the more wrong you will be. Using empirical data from past iterations to project future progress is good as long as all the relevant factors remain the same, so keep team composition the same. Use wideband Delphi technique to estimate work that will take months or years. Don't try to break these down too much, because you can't think of everything in advance. On smaller items, story pointing works as long as everyone understands the concept of relative estimation (most don't), so get a coach to teach and facilitate this exercise. Identify a group of baseline stories of different sizes for comparison.
When estimating epics in agile projects, consider time-based estimation and complexity. Break down epics into tasks, assign timeframes, and assess complexity. These factors determine the effort required. To account for contingencies, allocate additional buffer time or resources. This allows for unforeseen delays. When multiple teams are involved, coordination is vital. Engage teams in estimation, maintain communication, and align understanding. Consider interdependencies and potential impact when adding contingencies. Regular sync meetings and collaboration tools aid team coordination, ensuring cohesive project delivery.