Stakeholders and Feedback in the Scrum Community
by
Join the DZone community and get the full member experience.
Join For FreeI 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?
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
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.
scrum
Published at DZone with permission of Sean Mchugh, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments