Discovery and Re-estimation in Scrum: Clarifying Boundaries and Best Practices #216
Replies: 1 comment
-
|
Thank you @GabrielRCezar - the preservation of original sizing and comparison with the latest sizing is not encouraged for complex work, as the level of work is unpredictable. Product Backlog Items that are not Done (according to the Definition of Done) get zero credit. So carry over can result in claiming less credit as the work gets smaller, and that's frankly tough luck. The game is the harvesting of value, not activity. We even encourage splitting items when they get too big as long as they still have potential for value and are not activity items. I can always tell I have a lot of coaching work when comparisons are done. People should strive for improving discovery/delivery value validation over focus on nonsense metrics like predicted vs actual. In Scrum.org's Professional Scrum with UX, review of the Lean UX canvas is encouraged during (extended) Refinement, and discovery work can be included as separate items or items blended with delivery. I would encourage you to take another look at the Cynefin appendix section and the documents it links to. If I get around to doing a video or blog post on this topic, I'll add the link back here. Let me know if you have any follow-up questions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The Scrum Guide Expansion Pack 2025 acknowledges that discovery is a vital part of value delivery. It should be made transparent in the Product Backlog and Sprint Backlog and discussed during Scrum events. However, it is not formalized as an official Scrum event. Given its role in hypothesis validation and risk reduction, would it be beneficial for discovery to be treated as a formal event within the Scrum framework?
Additionally, the guide states that Product Backlog Items (PBIs) may evolve at any time, even while being worked on, and that Product Developers are responsible for sizing. While best practices suggest avoiding changes to the size of items already in progress to preserve predictability, the Expansion Pack allows for re-sizing when new information emerges.
In this context, if a PBI was originally estimated at 8 points and partially completed during the Sprint, is it acceptable to re-estimate the remaining work as 3 points for the next Sprint? Or should the original estimate of 8 be preserved to maintain transparency and traceability?
Beta Was this translation helpful? Give feedback.
All reactions