In this article Christiaan Verwijs & Barry Overeem will bust the myth that the product backlog is only maintained by the Product Owner: https://medium.com/the-liberators/myth-the-product-backlog-is-maintained-exclusively-by-the-product-owner-af51bc62e90f
Four Steps to Keep Your Product Backlog Small and Manageable
You should always strive to keep your product backlog small and manageable. With too many items on the product backlog, three problems arise:
First, it is harder to work with an excessively large product backlog. Time will be lost looking for items. (“I know it’s in here somewhere.”) Prioritizing the backlog will take longer. Duplicate items will appear as it will be easier to add an item “just in case” rather than be sure it’s not already listed.
Second, the development team barely notices any progress they make. A team that finishes 10 of 50 product backlog items can sense that they’ve made progress. A team that finishes the same 10 but out of 1,000 items will not feel the same sense of accomplishment. They will begin to wonder if it would matter if they had only gotten 9 done instead.
- Delete Things You’ll Never Do
- Keep Items You Aren’t Ready for Off the Product Backlog
- Periodically Review the Product Backlog
- Don’t Add Things Unless You Plan to Do Them Fairly Soon
Read the complete article there: https://www.mountaingoatsoftware.com/blog/four-steps-to-keep-your-product-backlog-small-and-manageable
Working with Stakeholders Who Won’t Take No for an Answer
Sign up to receive weekly tips like the one below from Mike Cohn to Help You Succeed with Agile here: https://www.mountaingoatsoftware.com/email-tips
Do your stakeholders have a hard time accepting a “no” from the team? Or put another way, does your team have a hard time telling the stakeholders that what they want is impossible? If the answer to either of those questions is yes, you are not alone.
I’ve found two techniques useful in communicating a “no” so that stakeholders listen and understand.
First, the team should establish a track record of planning projects accurately and meeting most commitments.
You don’t need to be perfect, but if a team meets most of its commitments, the business is more likely to listen when the team says something is impossible.
Second, when telling a stakeholder that a proposed date cannot be achieved, offer alternatives. For example,
- By what date could the functionality be delivered?
- Are there especially challenging requirements that could be relaxed to meet the deadline?
- What could be done to make the date feasible? More people? Stop using the team for second-level support?
Stakeholders often want more than can be delivered by some date. This shouldn’t be the team’s problem alone.
Wanting more than can be delivered must be viewed as a shared problem. A solution can only be found by the business and team working together.
When stakeholders trust the team’s commitment and work together with team members to find solutions, they all succeed with agile.
Patterns for Splitting User Stories
Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.
Read the complete article here: https://agileforall.com/patterns-for-splitting-user-stories/
The Product Management @Scale game: How can Product Owners scale their role?
Now that many
Read about it here: https://medium.com/the-liberators/the-product-management-scale-game-a-simple-way-to-figure-out-what-a-product-owner-should-do-cc143cb85ecd
Why Agile Teams Should Estimate at Two Different Levels
It is very common for agile teams, especially Scrum teams, to estimate both their product backlog and sprint backlogs. In this article, Mike Cohn will address:
- Why estimating both the product backlog and sprint backlog can be useful even though it seems redundant
- Why teams should estimate the two backlogs in different units
- When teams should estimate
- Whether all teams should estimate
Although I think you should not try to use hours for estimation, I agree using different valuations for an estimation is best. I find using T-shirt sizes for PBIs and Story Points for SBIs work well.
Read the complete article here, and also take note of some excellent comments at the bottom: https://www.mountaingoatsoftware.com/blog/why-agile-teams-should-estimate-at-two-different-levels
Pac-Man and Priority: A Backlog Story
What does Pac-Man and prioritizing a backlog have in common? Read it in this great article: https://medium.com/serious-scrum/pac-man-and-priority-a-backlog-story-e31632eb3921
The Liberators build their website
The Liberators build their new website with a Scrum Team within a week. In these posts and videos, they share what they’ve learned about flow and releasing more often – with examples that are as real-life as imaginable 🙂
Read the complete articles here:
https://medium.com/the-liberators/how-we-built-theliberators-com-incrementally-93d5095db4ab