Priya PatraDelivery Director| Capgemini India Technology Services LtdMumbai, India
Incorrect Backlog creation and refinement are major issues in many Agile engagements. What do you think should be a characteristics of a good product backlog. Do we have any best practices from your experiences for backlog creation and grooming ? I would love to know your thoughts on this. Saving Changes...
Few suggestions are :
1. PO needs to have a clear vision about the product
2. Stakeholders and Team members should have easy access to the backlog, so that timely feedback and necessary inputs could be obtained on the backlog
3. Good prioritisation techniques (like Kano, MosCoW models, CoD) need to be used by the PO and this is where SM can help the PO in recommending good techniques
4. PBI needs to be periodically refined and PO should have the PBI ready for next 2 sprints
5. Backlog should be kept concise and manageable in size (avoiding too much of unnecessary items in it) Saving Changes...
"Detailed Appropriately. User stories on the product backlog that will be done soon need to be sufficiently well understood that they can be completed in the coming sprint. Stories that will not be developed for awhile should be described with less detail.
Estimated. The product backlog is more than a list of all work to be done; it is also a useful planning tool. Because items further down the backlog are not as well understood (yet), the estimates associated with them will be less precise than estimates given items at the top.
Emergent. A product backlog is not static. It will change over time. As more is learned, user stories on the product backlog will be added, removed, or reprioritized.
Prioritized. The product backlog should be sorted with the most valuable items at the top and the least valuable at the bottom. By always working in priority order, the team is able to maximize the value of the product or system being developed."
I would also stop using the term "grooming" and use the more politically correct term "refinement" when referring to the ongoing care & feeding of the backlog.
It is a good practice for the PO (leveraging support as needed from BAs/BSAs) to refine the backlog on an ongoing basis. It is also important for the team to spend a bit of time each sprint (assuming a sprint-based approach) doing look ahead modeling/planning to make sprint planning more efficient - this activity was not defined in the Scrum Guide but is a valuable add-on recommended by Disciplined Agile Delivery.
Kiron Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Not much to add to what Girjia shared above. The impacts of an unrefined backlog seep into the efforts of the team causing delays, significant back & forth discussions, and even some frustration amongst the development team. A common mistake is not making refinement a continuous activity and at a minimum should be one sprint ahead to ensure the backlog is ready for sprint planning and building of the sprint backlog. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
There are big missunderstadings that contribute to fail in the matter. First, product backlog is not about Agile environments only. Product backlog is something used from 1956 up to date in multiple domains and approaches. Is not about Agile, is not about Scrum Second, when you ask "what is product backlog?" lot of definitions comes. So, the first thing to do is to take clear the definition. That applys to your initiative and to your team. Thrid, there is not somethig like "good" or "bad" product backlog. What exists is something that are not requirements (then you can not create something from them) until you take them are start the process to create requirements from them Saving Changes...
