The current version of The Scrum Guide is getting updated and here are the things I wish the new updates could address.
Daily Scrum – Change the third question at least . I have written more about it here
Development Team: (a) The term “Development Team” is often confused with waterfall Development Teams. Same term, two different meaning. While people learn about it in the class (like CSM), with knowledge decay, people forget and start conflating it with waterfall “development teams”. And you know this when they ask questions like, “Then who does QA?” (b) While Scrum has its origin in Software, it has also gained traction in other domains (like marketing, education, non-profit, etc). The term “Development Team” might be more appropriate to software teams and engineering teams, but probably less appropriate to other domains. Hence we need a better term. And it has been considered, but I do not know if it will change.
Product Owner – (a) Clarify Product Owner as the “chief decision maker” (i.e. the Dev. Team can also make decisions on Product Backlog as long as directed by the PO, however the Product Owner remains accountable and hence the chief decision maker) (b) With respect to Product Owner, sometimes, the terms responsibility is ambiguously used to mean accountability (eg – “The Product Owner is the sole person responsible for managing the Product Backlog, but also “The Product Owner may do the above work, or have the Development Team do it.” Another instance – ” The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering “. I would personally prefer “accountable” instead of “responsible”) Responsibility can be delegated, accountability cannot be. I wish it gets clarified.
Sprint Backlog and Incomplete PBIs at the end of the Sprint: Unlike Product Backlog, which is a living artifact (” Requirements never stop changing, so a Product Backlog is a living artifact “) I wish we can get a little bit more light on Sprint Backlog. Is the Sprint Backlog persistent (as long as we are sprinting?) Or does it die at the end of the Sprint? And what happens to incomplete PBIs at the end of the Sprint? Do you re-estimate or not re-estimate? When a Sprint is canceled, there are clear guidelines (” All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog “), but no guidelines when it is a normal Sprint. I guess these deliberately and intentionally left open. If you take a PSU course, you will learn that there are UX tasks, that are part of the Sprint Backlog, that take more than one Sprint to complete. Hence some elaboration on this topic would be great
Acceptance of Work by Product Owner: Under the “Cancelling a Sprint: section, the Scrum Guide states that, “If part of the work is potentially releasable, the Product Owner typically accepts it” . This raises a few questions – Does the PO “accept” work during the course of a “normal” Sprint? What if the PO is not “accepting” the PBIs and the increment might meet the Definition of Done? I would personally may be reword it as ” “If part of the work is potentially releasable, the Product Owner typically validates it and ensures that it can be used later”
Increment: PBIs can be deployed continuously throughout the Sprint as long as everyone share this understanding (it is a misconception that you have to wait till the end of the Sprint). Sometimes, inspecting a PBI that has already been released during a Sprint might be too early (we do not have enough usage/analytics info) or too late(the ship has already sailed). Based on the feedback in a Sprint Review, you might have to rollback your features, but that might also mean that some people who might have started using it may not like it. Yes, you can release with feature flags or use targeted release techniques, there are some workarounds, but I am not aware of a straightforward way to tackle this. And maybe Ken and Jeff already have a plan to address the wordings in the Scrum Guide to tackle this, I do not know.
What is the Product: The term “Product Backlog” appears 63 times in the Scrum Guide and term Product Owner appears 37 times. Yet, no specific guidance or recommendations are offered on how to define a “product”. If Ken and Jeff could add that to the Scrum Guide, many people might find it useful
PS: This list is just my personal perspective and not based on any other information. Also, there is no guarantee that the updated Scrum Guide will contain any of these. You can submit your own recommendations at Scrum Guide User Voice
Helping Teams and Organizations be Agile 