Do INVEST user stories make a sprint goal obsolete?
The SCRUM guide does not explain how exactly a PBI has to be defined.
Let's assume team A has a PBI, which ist defined as an INVEST user story
- "As user I would like to buy items in the game in order to get an advantage over other players"
Team B (which is working on a similar project) has the following PBIs in their product backlog
- "Shop: frontend workflow"
- "Shop: backend implementation"
- "New login screen"
By implementing their user story team A can ship a valuable product increment, while team B has to define a sprint goal (like "Provide a shop system for our users") to get the stories 1 and 2 implemented in the sprint (without a goal they would probably do 1 and 3, who knows...).
Team A actually does not need any sprint goals, since all PBIs are valuable, independent and testable (therefore they should be potentially shippable, too). Their sprints do not fail, as soon they complete at least one user story.
My question is also: do INVEST user stories make a sprint goal obsolete? Please share your thoughts and experiences about this topic.
Hi Artjom,
maybe this blog post can answer your question.
https://www.scrum.org/resources/blog/11-advantages-using-sprint-goal
Nils
Team A actually does not need any sprint goals, since all PBIs are valuable, independent and testable (therefore they should be potentially shippable, too). Their sprints do not fail, as soon they complete at least one user story.
My question is also: do INVEST user stories make a sprint goal obsolete?
What does the Scrum Guide say about a Sprint yielding one coherent function? If each individual PBI planned into a Sprint Backlog satisfies the INVEST criteria, would coherence among the items be assured?
@Ian Mitchell: Sorry but if I'm asking if some statement X in the scrum guide makes sense in a special case, the answer "what does the scrum guide says about X?" does not help me a lot.
"The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives."
In my point of view, the scrum guide forces the evidence of a sprint goal because of the lack of PBI quality definitions. By forcing the coherence the sprint outcome will become valuable and shippable. In case of INVEST PBIs you don't need the coherence among the items to produce valuable product increment. It is also not so easy to find coherence between PBIs that are independent by design.
In my point of view, the scrum guide forces the evidence of a sprint goal because of the lack of PBI quality definitions. By forcing the coherence the sprint outcome will become valuable and shippable. In case of INVEST PBIs you don't need the coherence among the items to produce valuable product increment. It is also not so easy to find coherence between PBIs that are independent by design.
If it is sufficient to force the value of an increment, then there may be little point in using Scrum rather than another lean or agile means of delivery. Issues to consider are:
- Might a single coherent function contribute more than the sum of its parts?
- Could meeting a Sprint Goal help to bring a complex problem domain under better empirical control?
- Does a Sprint Goal allow greater risks to be mitigated than can be adduced by individual product backlog items, however well defined they might be?