There is a difference between the forecast and the Sprint Backlog in Scrum. Exactly what this difference is, has eluded me for some time, and it may very well be unclear to you too. The difference may seem subtle but can have real practical benefits as you will learn below.
Continue reading here: https://www.scrum.org/resources/blog/difference-between-forecast-and-sprint-backlog-scrum
Dominik Maximini has created a nice video where he explains the paragraphs about the Sprint Backlog from the Scrum Guide.
Carsten Lützen created a lot of introduction videos that can be found here: https://www.youtube.com/channel/UCDvr4dS873jCpYDCEtBBW8g/videos
Some exampels of these video’s are:
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
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/
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