By Nathan Donaldson
Tags: Agile
Today’s post in our introductory series on user stories is about how you can use user stories (and other tactics) to engage stakeholders in an Agile project.
It might sound as if user stories are being proposed here as some kind of magic bullet for any and all project woes. They’re not. User stories are a tool. Like any other tool, if they’re badly used or ill-supported they won’t bring you the benefits you were seeking. Equally, when well used they not only underpin a very effective development process but can also be used to communicate project progress and decision points to people outside the development team (a.k.a. stakeholders).
As noted in the post about the development process, in an Agile project there are three roles: Product Owner, Scrum Master and team member. Only people doing actual work are in the team. Only people who are in the team go to stand-ups, retrospectives and planning sessions. It might sound blunt, but that’s the way it works best.
I usually define “stakeholder” as a person outside the team who has a direct interest in the project’s outcome. (This is another good definition.) They might be paying for the project, they might be ‘sponsoring’ the project within an organisation, they might be the people who work with the end customers. They are the people who the Product Owner needs to take direction from and report back to.
The relationship between the Product Owner and project stakeholders can be a delicate dance. Ideally, the Product Owner will be someone who the stakeholders really trust. The Product Owner is constantly making decisions for the project, and needs to have the confidence to make these without referring back to the stakeholders in each instance. Equally, the Product Owner needs to keep stakeholders advised of progress, and get sign off on any necessary decisions.
I’ve been the partner in these dances before, and I’ve learned it’s something you get better at the more you practice. Here are a few things that I’ve found work well.
Before you start writing user stories or anything else, bring the whole team and all the stakeholders together. Get the stakeholders talking about who their customers are, and what they want to make for them. We’ve put together a kick-off meeting toolkit to help you plan and run a one-day kick-off.
In these meetings, we often use a variation on the project success slider tool to understand the environment we’re working in. Often stakeholders are under pressure: a limited budget, a tight timeframe, a group of customers who they need to deliver a new service to.
At Boost we used a modified version of the sliders, where each factor can be awarded a value between 1 and 7, but only 28 ‘points’ are available to be awarded. We find the exercise has two benefits:
I don’t advise getting stakeholders involved in writing user stories, or doing the prioritising. However, they are likely to want – and warrant – insight into what’s being prioritised and why. And you as product owner need to make sure you’re still making decisions according to the business’s needs (and that the business needs haven’t been changed without anyone telling you).
A technique that’s worked well for me in the past looks something like this. The afternoon before the sprint retrospective, but after I’ve prioritised the user stories for the coming sprint, I have a meeting with the project stakeholders/sponsors. I show them the work that’s been completed since we last met, and present anything that needs to be signed off as a milestone. I explain what I’m trying to achieve in the next sprint. Then I confirm that my priorities are still the right priorities.
I usually use Pivotal Tracker and show stakeholders a view where completed stories are presented in one column, current sprint stories in the next column, and the unstarted stories in the last column. It’s a project update in one screen. Then if they chose to reprioritise anything, they watch on the screen as I drag and drop stories around. It demonstrates very effectively the impact of these decisions on when work is likely to get done.
Because the focus with Agile is on regularly delivering deployable software, you’re in the happy position of frequently showing stakeholders completed chunks of work. And because user stories are written in plain language, when you look at a list of completed stories it’s easy to understand exactly which features and functionality have been completed – even if you’re delivering something hard to demonstrate, like setting up a server or fixing bugs.
Between demonstrations and the user stories, I’ve found there’s rarely any need to write project update documents. It’s obvious what’s been completed, and what remains to be done. It’s also possible to see if you’re working more slowly than you expected, and therefore need to start thinking about getting more people into the team, or freeing up more of existing team members’ time for the project.
The things you’re already doing as part of an Agile project make good communication tools when you’re talking to people outside the project. You can do reporting without the overhead involved in writing reports, and you can stay within the spirit of the process. All of this helps develop people’s understanding of how web and software projects happen.
Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.
Learn more about working with stakeholders in Scrum.
