User stories creation is a useful mechanism for expressing product features collaboratively. However, having sprint goal as list of user stories, based on team velocity, from my view reduces the business value of the sprint.
The sprint business value should:
– Target organization objective, which can be far from merely list of user stories or detailed technical features.
– Business goal represents the level of control exercised by management on the team. For management, the user stories represent a detailed level which can cause distraction. It is the product owner duty to ensure the proper implementation of user stories.
– Limiting the sprint goal as merely a list of user stories misleads the organization. User stories mentality lends itself to judging teams on how much stories that can deliver per sprint (velocity). Getting obsessed with velocity can lead to situation of ship traveling high knots/hour but in wrong direction.
Let me give examples of sprint goals which might not be primarily represented as user stories.
1. Knowledge transfer of area in the application so that it can be maintained by internal team. This will save $50,000 of vendor maintenance contract.
2. For an application which requires bi-directional testing from the vendor and client, a goal of a sprint could be arriving at mutual agreement on how business scenarios can be handled by both parties.
3. Improve automation in the processing cycle to allow reduction by x% of existing man-hours spent in manual house keeping.
4. Allow old functionality to run on the new developed platform leading to $x in saving in maintenance and operations.
5. Provide end-user features for self-configuration of the application which will reduce the cost of maintenance by $200,000 a year.
- Each of the previous examples can have underlying user stories. But each goal was refined from one sprint to the next instead of being decided from up-front. If you have sprint goals equivalent to list of user stories from the product backlog, means we know the goals early in the project. My argument, goals are to be discovered!
- Though an application can have quantitative objective as part of the project charter, sprint goals evolve and continuously feed the charter with new business benefits.
- The Agile project for me is a discovery endeavor more than being a construction activity. Focusing on user stories means we became construction oriented.
- Another way to look at this is that sprint goal is a business objective that is set by the product owner and agreed-on with the team. From my view, the team should be responsible on creating the user stories which can fully or partially support the goal.
- The product owner is the captain of the ship for discovering. He sets short-term objectives (sprint goals) which the crew (the scrum team) can commit to achieve by sprint-end.