Join the DZone community and get the full member experience.
Join For Free
Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.
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)
- 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.
Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.