Is My Product Backlog Just a Laundry List?

In simple terms, a product backlog is a list of everything that needs to be done in relation to the product. This is the key artifact that helps in translating the high-level product vision and serves as the foundation to initiate the development of the product.

This is beneficial in comparison to the waterfall approach of creating multiple pages of requirement documents because it provides prioritization so that the team has a direction, has the necessary details required by the team, and it keeps evolving and responds to change.

In order to manage the product backlog and avoid making it another requirement document, I would suggest the following pointers:

The Product Backlog is prioritized by the team according to what is deemed to be of high value followed by the low-valued items. The high priority items at the top should follow the DEEP acronym of being detailed appropriately, estimated, emergent and prioritized so that it could be executed in a single sprint. I recommend that the Product Backlog should be managed like the shape of the iceberg as suggested by Mike Cohn. Items will become bigger as we approach the lower part of the iceberg. As the top items are being completed, the lower items will reach the top, which helps the team to work towards the product goal with more focus. We should also ensure that the team knows the difference between “Prioritizing” and “ordering." There will be inputs about the items from various sources, which could be stakeholders, senior management, the marketing team, or any other team unrelated to building software. All these inputs should be clearly validated, and the value of the item should be determined. Does prioritizing this item takes me closer in completing the product goal and will it give the expected ROI? This should be thought of whenever we assign a priority to the item. Prioritizing is a skill. Most of the time we may end up with a backlog where every item is a high priority. So, I recommend starting with techniques for prioritization, like MoSCoW model, Kano model, or Stack Ranking. This helps with focus and builds the capacity for prioritizing, and as the PO and the teams progress in the journey, prioritization becomes their second nature. When it comes to the product backlog, as per the Scrum Guide, the Product Owner is the person who has full authority of determining what goes in and comes out of the product backlog. While managing the Product Owner, he should maintain a balance and ensure that maximum business value is achieved. He should adopt best practices of regular grooming sessions with the development team, ensure there is no gap in communication within the team, and make sure product backlog items are more detailed as they get moved to Sprint backlog and the release plan. The product owner can maintain a separate parking lot kind of list for other ideas related to the product instead of adding them to the backlog.   The common trend observed in large organizations is having a proxy PO in the place of a dedicated PO per squad. However, to have a healthy backlog it is important to have a dedicated Product Owner who is solely dedicated and is not shared between teams. In instances where this becomes impractical, I recommend that, even if there are proxy POs, they need to share the same vision as the chief PO. As Roman Pichler suggests, it's critical to have a big PO when the product is in discovery and is evolving and multiple POs during the maturing stage. Even though the Product Owner owns the product backlog, the Scrum Master must also closely work with the PO. The Scrum Master should support in backlog grooming, clarify the product vision, and check to see if the team is in the correct pace towards achieving it, resolve any dependencies of the PO from the team, ensure there is no miscommunication, and be working hand in hand with the Product owner to bring the vision to reality.  In order to manage the product backlog effectively, it is more important to keep monitoring if there are any anti-patterns at any time. I had noticed some anti-patterns as below:

The product owner should only have the final say on prioritizing, and it should not be influenced by anyone, including the stakeholders or senior management. The product owner should be vigilant of what exists in the product backlog, since having too many items might not be realistic for completion, and should eliminate any waste periodically. Themes or Epics should not be ignored while structuring of the product backlog. User stories in the product backlog should not be a copy of the requirement document but should have the INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable) principle applied. DoR (Definition of Ready) not being updated for product backlog items

I have the experience of working on product backlog while creating our start-up product, beginning with the MVP (Minimum Viable Product). We adopted the lean start-up Build-Measure-Learn concept, starting with user interviews, brainstorming ideas, developing prototypes, experimenting with users, gathering feedback, and ultimately improving the product.

For this, I used Roman Pichler’s Vision board to capture the product strategy and from the board created User stories to be included in the Product Backlog. The PBIs were organized by Epics and related user stories were grouped under Themes. We also engaged the users of the product while drafting the user story to understand what they need as a user.

As a Product Owner, I gathered inputs from customers, the CTO, and Marketing Lead and then prioritized the PBI based on value generated and included them to the upcoming Sprints. The technique I used for prioritizing was Moscow (Must-Have, Should-Have, Could-Have, and Won’t-have), which helped me to categorize the user stories into different buckets, and it was easy to negotiate on the items with the team.

Being a start-up, it was challenging to prioritize as the customers and the stakeholders had their own views of value. In those times, we adopted vertical slicing of user stories and were able to show them the product features in increments, which were welcomed very well!

How to avoid filling your backlog with trash:

I feel that when we as a team commit along with the product owner to having a specific set of Must-Haves and don’t view the product backlog as just a laundry list of items, it's much easier to manage the product backlog. Also, as always, we need to make sure we have an agile mindset and work as a team to achieve the desired outcome.

Source: Dzone.com

Powered by NewsAPI.org

Keywords:

Scrum (software development) • Graph (discrete mathematics) • Scrum (software development) • Binary relation • Software development • Waterfall model • Requirement • Scrum (software development) • Scrum (software development) • Scrum (software development) • Iceberg • Mike Cohn • Yung Berg • Product (business) • Information • Stakeholder (corporate) • Senior management • Marketing • Software • Information • Value (economics) • Product (business) • Goal • Thought • Skill • Moscow • Kano model • Vitality curve • Hold Your Fire • Scrum (software development) • Scrum (software development) • Scrum (software development) • Scrum (software development) • Scrum (software development) • Scrum (software development) • Sprint Corporation • Planning • Scrum (software development) • Organization • Scrum (software development) • Roman Pichler • Scrum (software development) • Scrum (software development) • Scrum (software development) • Scrum (software development) • Communication • Scrum (software development) • Computer vision • Scrum (software development) • Surveillance • Anti-pattern • Anti-pattern • Scrum (software development) • Stakeholder (corporate) • Scrum (software development) • Scrum (software development) • Scrum (software development) • User story • Scrum (software development) • Requirement • Scrum (software development) • Scrum (software development) • Startup company • Minimum viable product • Minimum viable product • Startup company • Machine learning • Concept • User (computing) • Idea • Prototype • Feedback • Roman Pichler • Goal • User story • Scrum (software development) • User story • User (computing) • User story • Scrum (software development) • Information • Customer • Chief technology officer • Marketing • Moscow • User story • User story • Scrum (software development) • Scrum (software development) • Scrum (software development) • Agile software development •