When we talk about Scrum for complex Product Development, it starts from Vision and Product Backlog.
As per Scrumguide - “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of the requirement for any changes to be made to the product.”
In other words, the Product Backlog is a set of requirements that are needed for the Product. These requirements are functional requirements (FR), non-functional requirements (NFRs), defects (BUG), capabilities (CAP), explorations (POCs), etc.
These are documented in tools such as excel, JIRA, TFS and many more. Also, they are made available/accessible to the scrum team and stakeholders.
When Product Backlog initially takes its shape, it is available to the team and stakeholders. However, doesn’t help in making any decisions and observations and hence is only visible.
What does it take for the Product Backlog to be transparent or What information does a product backlog give about the Product?
The Product backlog raises transparency when business is able to take decision based on what is available in the Product Backlog. To make Product Backlog transparent, the Product Owner works with stakeholders and team for an understanding of the value and estimate of the work and then orders the backlog for maximizing its value.
As the Product development progress, the Product backlog get’s
- The business value for the PBIs in the Product Backlog, that helps with Product Backlog prioritization. Product owner runs a variety of workshops with stakeholders and team to have value for the Product Backlog Items. The commonly used techniques for assigning values are 500 Value Point, Value Pokering, buys a feature and many more.
- Refining the bigger Product Backlog Items, here, more information regarding the requirement is discussed within the team. And also, the requirement(Product Backlog Item) in the Product Backlog gets decomposed for a better understanding, implementation and estimates.
- The further deposition of the backlog and techniques such as value stream, story mapping, customer journey, value proposition, etc helps to define the minimum viable product (MVP) and Product roadmap, where it presents what Product features will be delivered at what timelines and in releases.
Product Owner forecasts on the Product Backlog every sprint
When your Product Backlog is ordered and estimated; it reflects on the Product Roadmap; making it easier for stakeholders to plan their work well. Similar to marketing and sales professionals who plan for the campaign for the new feature releases of the Product or launching the product.
A good technique for the predictability and forecasting of the Product Backlog could be the velocity of the team. The velocity is often confused with the productivity of the team. In my next blog, I shall discuss what velocity is all about and how this can be used as a tool for the Scrum team’s predictability and forecastability.
