The Product Backlog Board
This post presents a structured and hierarchical product backlog board that considers non-functional requirements and display high priority items that are ready to code.
This post presents a structured and hierarchical product backlog board that considers non-functional requirements and display high priority items that are ready to code.
In this blog post, Mike Treadway explains the technique of using story points for story estimation during agile planning sessions.
It’s obvious, but warrants mention: What we do in the future is likely to be different from what we’re doing today. The implications for user stories should be obvious: User stories are temporary. Saving them for posterity doesn’t serve the primary purpose of user stories, and doing anything that makes them less temporary can turn user stories from benefit to detriment.
Some people want to take the stance that no work should be done in advance of the sprint. That is clearly untenable. To see why, let’s take that view to its extreme: If we did nothing in advance to understand what we’re building, we’d show up at the planning meeting and say, “Hey, what should we build this sprint? We were working on an eCommerce site yesterday, but I think maybe we should switch to writing a word processor…” The team would literally have nothing written down—no product backlog / user stories / prioritized feature list at all.
The article “<a href=”http://www.mountaingoatsoftware.com/system/article/file/12/UpsideOfDownsizing.pdf”>The Upside of Downsizing</a>” describes how a project was successfully downsized from 100 to 12 developers. To make such a dramatic adjustment the development process was switched to Scrum and user stories.
Scrum Expert Copyright © 2009-2023 Martinig & Associates