Leadership in Scrum through evolving goal definition

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.


  1. 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!
  2. 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.
  3. The Agile project for me is a discovery endeavor more than being a construction activity. Focusing on user stories means we became construction oriented.
  4. 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.
  5. 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.

One thought on “Leadership in Scrum through evolving goal definition

  1. I do not know if it’s just me or if everyone else experiencing problems with your website.
    It appears like some of the text in your posts are running off the screen.
    Can somebody else please provide feedback and let me know if this is
    happening to them too? This may be a issue with my internet browser because I’ve had this happen previously.
    Thank you

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s