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 Gathering Software Requirements Use Cases
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting. Continue Reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates. Continue Reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good. Continue Reading