In this article, Christophe Le Coent discusses how you can express a Scrum product backlog to provide enough planning information to management but still following the Agile principle that “welcome changes over following a plan”.
Agile Scrum backlog grooming and management
In his article “Creating an ATDD Ready Sprint Backlog in Scrum“, Ralph Jocham discusses the requirements definition in Scrum and how examples allows the team to better understand them. As the backlog is now also expressed in terms of business requirements, each team member can easily focus on the bigger picture during the Scrum stand-up meeting and align with the ‘why’. If you translate the business-facing examples into automated tests, it enables the team to verify during the Sprint that the software increment always meets the evolving requirements towards the Definition of Done and the overall goal.
In this article, Vaidhyanathan Radhakrishnan discusses about the value of release planning in Scrum. This is the tool to schedule timelines for a project or a product in a complex environment where the outcome of one team is required for the other teams. The article proposes an approach to produce a release plan. This approach is based on the finding primary and secondary features in the product backlog. You can then determine whether the resources are adequate and what interdependencies exist to adjust the feature layout. The article presents the advantages of a release plan and the common disadvantages of this situation, like including ongoing or generic activities spread across the timelines which dilutes the focus of the plan.
This article discusses the the role of the Product Owner in moving a backlog item to done. It explores how to achieve the productivity benefits of an up-front enabling specification, given the reality that Scrum is an empirical framework in which emergent understanding of the story under development is inherent.
Uncertainty in Product Backlog is a big risk for the project schedule. The problem is that the full scope of the release can be quite hard to estimate because the requirements are not well-know early on. Confounding this problem is that frequently the release date is a hard deadline. This means that a team must perform an unknown about of work in a fixed amount of time. The “Cone of Uncertainty” describes the reduction of the uncertainty about scope after each iteration. At the uncertainty is eliminated and the exact amount of scope is known.
In the past, the Scrum Guide consistently used the word “priority” for the Product Backlog or noted that the Product Backlog was “prioritized.” While the Product Backlog must be ordered, prioritization is only one technique and rarely a good one to achieve this objective. The new Scrum Guide instead uses the term ordered for the Product Backlog.
A survey says that 64% of the functionalities included in software products are never or almost never used! In this blog post, Emiliano Soldi shares some ideas on how to avoid this and prioritize user stories.