How can you estimate Product Backlog Items effectively?

Relative sizing works well in most use cases. I recommend to add affinity estimation techniques in which you not only estimate the relative size but also team gets an opportunity to re-verify the estimate in comparison to other stories. Let’s assume team estimated two stories with both having 8 story points. Now, they have an opportunity to look back if both of them require same efforts, if not revisit the estimates. By repeating this affinity estimate we can reach more precise estimates. In affinity estimation, same sized stories are grouped together and compared to find possibilities of improvement in estimation.

In my experience, estimating product back items effectively is to have 1. Basic domain knowledge 2. Understanding what’s not needed 3. Analysing what’s needed 4. is this necessary to develop 5. Is this PBI has more ROI 6. Everyone should have knowledge on what is that being worked upon 7. Being transparent on this doesn’t work or works

When applying relative sizing, your team might feel insecure about providing estimates, especially if it's a new team where members are learning how to work together. Reinforce the idea that the method employed is based on the team's perception, and there's no problem in assigning a number to a task if you're not entirely sure how to do it; it's okay to make 'mistakes.' It's also crucial to have senior members share their past experiences and provide examples to help the team develop a better understanding of how to make sizing estimates. Last but not least, it's important to define a single method. You can't learn how to measure if you keep changing the way your team perceives the measurement.

The best way to estimate for any team is to do via T-Shirt Sizing Techniques. This estimation Technique has following involved:- Must Haves- Features are first preferred as the value for the end users. This has to ba part of MVP. Should Haves- Once Must Haves are done then go for this. Could Haves- Not needed for now but can be good attraction factor for end. Users if they get something extraordinary at the start. Team can easily estimate using above three options and it's quite simple as well for them to get understanding of the estimation principles.

Effective estimation of Product Backlog Items involves collaborative discussions among team members. Leverage techniques like Planning Poker to gather diverse perspectives and insights. Consider factors such as complexity, uncertainty, and dependencies when assigning story points or time estimates. Regularly refine estimation practices based on past experiences and feedback, ensuring continuous improvement. Engage the entire team to foster a shared understanding of the work, promoting accurate and reliable estimates for successful sprint planning and delivery.

"No one knows more than everyone!" Involving everyone not only helps collaborate toward a given scope of work, but it also helps everyone to collectively develop systemic thinking toward the scope of work. And when that happens the team becomes a learning team. Unfortunately, members try to hoard knowledge in fear of losing their 'authoritative' position.

Involve your team members or stakeholders. Ask them to give an estimate on story points depending on the complexity. Also we can use historical data and velocity of the team to get the number of iterations required to complete all PBIs. Team can do some mock sprint planning where the team pulls out stories and identifies the tasks. The team will allocate time for each of the tasks and keep adding against the available capacity. Once the team reaches the optimal level of capacity, the team can identify the projected velocity.

Get into one or more backlog refinement sessions, work with the team to discuss and estimate the backlog items. Since the team is going to work on these, they're best suited to estimate these .

This is how we do it: - Break the tasks into smaller tasks as possible. - While giving an estimate, not only think about the task but also consider time for validating, testing, and the associated impact on other parts - Estimate along with your team members - consider the maximum estimate given by any team member with valid reasoning.

One of most crucial prerequisite before agile estimation is the whole team’s understanding of the business value of Feature of which the PBI is part of and how does it fit user journey map (and not just the PO and few senior members). Use planning poker to relatively estimate with respect to baseline ( a PBI done earlier where the whole team understands it’s effort, complexity) and when there is different estimate by team members, it’s an opportunity to clarify misunderstanding of effort, technical challenges, dependencies. A major benefit of agile relative estimate is this clarity it brings to all team members through discussion and consensus than the estimated value itself.

In addition to factors like complexity and uncertainty (due to technology challenges, dependencies, early user feedback etc.), an important factor is team’s knowledge about the domain and technology used. Relative estimation and discussion may reveal the need for training or knowledge sharing for team. Time spend in estimation is another factor. There is nothing like “accurate estimate”, because literally estimate means “an approximate calculation or judgement of the value, number, quantity, or extent of something.” Hence this human factor or urge to be more accurate and precise is worth a consideration for moving forward than spending lot of time in agile estimation.

Estimates are never accurate. The only aspect is how coincidental are the guesses to reality once complete. Accuracy might technically be the correct term on paper, but the term leads to ideas of false precision and control where it doesn’t exist. It can also lead to evaluating those who make the estimate on their ability to “guess”. In the end, no aspect of these dysfunctions are typically helpful or productive. The value of the PBI is also a hypothesis. The value is only known once data comes from leveraging the implemented solution to check the proposed hypothesized value.

Use techniques like story points, planning poker, and reference PBIs to aid in sizing. Engage the whole team for diverse insights. Use historical data and break down complex product backlog when needed. Regularly review and refine estimates to improve accuracy. Utilize tools like Jira for streamlined tracking and management, enhancing Agile practices."

Le business ou le fonctionnel reste supérieur à toute les estimations aussi précisent soient elles. Admettons que l'on a, grace aux expertises de chacun, obtenu un délai qui correspond à 95% à ce que l'on a observé jusqu'à présent. Et, là, changement de stratégie du donneur d'ordre. Il faut être prêt à tout jeter car tout a changé.

You should generally limit what is estimated to avoid constant comprehensive Product Backlog re-estimation. You want just in time estimations. Typically this is staggered with combining different types of estimations, eg T-shirt size, story points, hours (not advocating). The re-estimating is a crucial activity, as is re-reviewing the details of what you are estimating, questioning “knowns” if really known / still accurate. This consumes a lot of time, as it should. Being surgical in what areas of the product backlog are estimated, are volatile in details, proximity to when the work is undertaken, and team composition elements should help them decide where focus is the least-ish possibly wasteful.

Avec le temps, j'ai tendance à me dire que l'affinage de l'estimatiion vient avec la pratique. Il faut oser regarder l'équipe comme elle est vraiment en mesurant "tout". Par exemple, si on estimé qu'un PBI prend 2 mais que les juniors peuvent le traiter ce ne sera jamais fait en 2 les amis.

During estimation, team should be having conversations to understand the scope, complexity (dependencies on other teams), teams expertise doing similar work before. Story may need to be re-structured, may need to be split so that story delivers value, can be completed in a sprint. Having sub tasks would help team in understanding what needs to be accomplished. As and when team gets exposure, teams estimation accuracy would improve.

Effective estimation of Product Backlog Items (PBIs) in Scrum involves using techniques like Planning Poker, story points, or relative sizing. Break down tasks into smaller, manageable units for more accurate estimates. Collaborate with the development team to gain diverse perspectives, fostering a shared understanding. Consider historical data and use past performance to inform future estimates. Regularly refine estimates as the team gains more insights and understanding of the project. Ultimately, the goal is to create a realistic and achievable plan while fostering collaboration and transparency within the team.

Focus your efforts on the features, the PBIs that make up those features and how the team is going to deliver on them. Spend 99% of your time on the what and how so when they come to the last 1% that knowledge will be utilized so their estimations will be done quickly and with more accuracy. I often spend all but the last 5 minutes so leverage an artificial timebox and sense of urgency. Often times their gut estimates are as accurate or more accurate than if they spent minutes per story estimating with greater analysis.

En réalité ces outils servent à donner de la visibilité en interne et en externe. Je me dis à chaque fois que tout est faux car c'est l'expression idéale de ce que l'on savait à un moment donné. Si les choses changent vite on doit changer vite car il y'a de nouvelles données

Un cycle en V adapté à l'équipe bat à plate couture la meilleure méthode agile qui n'a pas l'adhésion des gens. Une méthode et technique est faite pour les gens pas l'inverse.