In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don’t have a “done” status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items.
As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common questions: What do Product Owners really do? Do we even need Product Owners?
The Agnostic Agile Oath is a movement that aims at recognizing the importance of being agnostic with agility at any level. As it is stated on the web site: “one size does not fit all, one framework is not the answer, and the what’s and the how’s of what needs to be done, should be suited to customer context and to a wider strategic vision.”
This is a talk about how shifting the focus from craft to product has affected my company. Our delivery teams are required everyday to make trade offs between what would the best technical solution and the one that is right for the product they are delivering. Ultimately, we get paid to solve business problems, not to be perfectionists.
User stories are one of the main format to record user needs in the Agile world. There is however a debate on the amount of information that should be available to the Scrum team before starting the sprint. In this article, Zuzi Šochová recommends to minimize the size of user stories and to define simple conditions of satisfaction instead of writing acceptance criteria.
Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos. Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes. Outcomes are the big picture that acts as an anchor for whole efforts and which is continuously broken down into more and more detailed product backlogs.
If one of the first aim of Scrum was to break the silos between business analysis, development and testing, you can consider that improving the cooperation with the operation side of IT as the next frontier in this journey. What is the point to produce potentially shippable software increment in two weeks if your database administrator doesn’t want more than three new releases windows for the production database?
Scrum Expert Copyright © 2009-2025 Martinig & Associates