Sumeet Madan — February 28, 2020 When we talk about Scrum for complex Product Development, it starts from Vision and Product Backlog.
What is the Product Backlog in Scrum?
As per the Scrum Guide — “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 can be 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 the Product Backlog initially takes its shape, it is available to the team and stakeholders. However, it 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 the enable business to make decisions based on what is available in the Product Backlog. To make Product Backlog transparent, the Product Owner works with stakeholders and the team for an understanding of the value and estimate of the work and then orders the Backlog for maximizing its value.
The business value for the PBIs in the Product Backlog, that helps with Product Backlog prioritization. The Product Owner runs a variety of workshops with stakeholders and the 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 streams, 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.
The Product Backlog raises transparency to the team and Stakeholders by continuously inspecting and adapting Also, forecast the roadmap and release strategies to them.
The 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. This is 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 for 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.
I welcome your feedback to improvise this article and will be happy to make it more effective based on your inputs.
Business & Finance Articles on Business 2 Community
(73)
