Agile Zone is brought to you in partnership with:

Sean McHugh is a Scrum Master at Axosoft who works with customers who are new to the scrum methodology. He also helps customer's who are experienced with scrum, but are beginning to implement a software solution for their scrum teams. He shares some of his thoughts and experiences at thescrumblog.blogspot.com. Sean is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Stakeholders and Feedback in the Scrum Community

02.07.2013
| 1585 views |
  • submit to reddit
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

Support:

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.

Sales:

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.
Published at DZone with permission of Sean Mchugh, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)