How can the product owner understand the dependencies between requirements when prioritizing user stories for each iteration in a Scrum environment? What if the implementation of a particular user story is dependent on another user story that has not been implemented yet?
Since we usually start a new theme or feature with a meeting to discuss the purpose of the theme, brainstorm technical implementations and break it into user stories, we can consider dependencies at this time and help the product owner prioritize the user stories in the correct order. Usually, the product owner (PO) gives us all the user stories for a theme, and we are free to work on them in the order that makes the most sense. The PO indicates which user stories are “must-haves” and which are “nice-to-haves,” which helps us plan how to work on them. This is one advantage of the self-organizing team in Scrum: We manage our own workload in the way that makes the most sense. After all, we were hired for our ability to deliver high-quality software. The business cannot tell us how to ensure the technical aspects of that quality. We have to take that responsibility.
This is another area where your team may need to experiment with different approaches. Some teams adhere to a rule that a user story must deliver value to the business. We don’t worry about that, as we may need user stories that build up infrastructure or make changes to our application or database model. Our team releases to production every two weeks. If a theme can’t be completed in one sprint, we use a system runtime property to “turn off” the new functionality and prevent end users from seeing or using it. That way we can release the theme when we’re ready. Teams that actually release to production less frequently may have different ways of ensuring that they have enough ready to release, which includes considering dependencies between user stories.
Dependencies also come into play when estimating user stories. Because we keep our user stories small, which helps with predictability and maintaining a steady pace, we will estimate stories in the order in which we think they should be done. If Story A is dependent on Story B, our estimate for Story B will be something like “Three points, assuming Story A is complete.”
Dig Deeper on Software development lifecycle
Related Q&A from Lisa Crispin
Agile expert Lisa Crispin explores the various meanings and offers tips to testers on how to work integration testing into the Agile development ... Continue Reading
Expert Lisa Crispin explains how and when to implement exploratory testing, automated regression testing and manual regression tests in an Agile ... Continue Reading
User stories play an important role when defining requirements and they also contribute to living documentation during the software development ... Continue Reading