Wednesday, April 13, 2011

Stakeholders and Feedback in the Scrum Community

I feel like stakeholders don’t always get the attention they deserve from the Scrum community. You hear all kinds of things about planning sprints, creating and managing stories, tracking the burndown and a whole host of other things important to Scrum but you don’t really find too much in the way of getting feedback from your stakeholders in the community.

Let’s fix that shall we?

Stakeholders are essentially any person or group of people who have an interest in your product that aren’t directly involved with its creation. Basically, anyone who isn’t a product owner, scrum master or team member is a stakeholder in your product and potentially a useful source for feedback.

This means that at the very least, your product owner should be actively engaged with these folks to obtain good feedback for the product backlog going forward. Start by getting in touch with these people
  • Customers (no brainer)
  • End-users (might be different than your customers)
  • Support
  • Sales
  • The Scrum Team

The first two fall into the “Duh” category so we won’t cover them too in-depth but the remaining three are sometimes ignored despite the fact that they bring a unique perspective to the product backlog. Let’s look at support first

Your Support team knows your product better than anyone (or at least they should), they know where all the performance problems are, the annoying behaviors, the most common errors and most importantly the things that your customers complain about but don’t bother to add to the backlog themselves. They’re also going to play an important part in the level of service that you can offer for your product, for instance you may see support put through a backlog item describing better error messages or logging in your application. While that type of request might not impact day-to-day usage of your software, it will make the level of service that support can provide that much better. Don’t forget to talk to your support team for feedback.

This one will be either more or less dependent based on how you sell your software but keep in mind that Sales spends their entire day talking to people who are considering the use of your product. Because of this, Sales is likely going to be the first place you’ll find problems that you can innovate an answer for.

The Scrum Team:
A lot of people forget that the Scrum team is a major stakeholder for the project. And their feedback will likely be an order of magnitude more removed from the end-user experience than any other stakeholders it’s still important. Look for backlog items such as “Refactor X”, “Rewrite Y”, “Consolidate Z classes”, “Simplify U API”. While these things may not directly affect your customer’s experience they do tend to affect either the stability of the final software or the speed at which you can add new features.

Bottom line, feedback should be a cornerstone of your product. Your product owner should be consistently contacting your customer base, support team and sales to find more feedback or to better understand the needs of their stakeholders. Once you know what needs to happen, the rest is just the mechanics of Scrum as we all know it.


Anonymous said...

"Scrum Master" can be thought of as a "Project Management Facilitator". There is no official PM on the project, the SM is the closest you will come.

The SM should be aware of Stakeholder Management principals and reporting techniques. As it happens, this is one of 9 management areas purported by PMI ( and described in great detail in the PMBOK (Project Management Body of Knowledge).

Sean McHugh said...

@Bryan It's true that the Scrum Master is probably the closest thing you'll find to a PM on a Scrum project but the stakeholder management will most typically fall to the Product Owner since it's his job to understand and represent the stakeholders to the team.
The Scrum Master's primary job here will be to facilitate collaboration between the Product Owner and the Scrum Team.