Welcome back!
So far in this series I’ve covered
- an introduction to user stories
- adding acceptance criteria to user stories
- user stories and the development process
Today’s post is about how you can use user stories (and other tactics) to engage stakeholders in an Agile project.
It might sounds like 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, and 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 (aka stakeholders).
What’s a stakeholder?
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.
Product Owners and stakeholders
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.
Kick-off meetings
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.
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.
Project Success Slider from LibraryTechNZ
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:
- Everything gets discussed out in the open, and the group has an objective and visual way of reaching consensus on what the project needs to do in order to be successful (e.g. “We’ll accept delivering beta software that’s 80% in terms of our quality criteria, if it means that we hit our deadline and we have all the functionality we wanted to get out there.”)
- An understanding is reached that can be used to make decisions later in the project. Say the group decided that staying within budget was more important than the timeline. Now imagine a scenario where a key team member has to take two weeks’ sick leave a month before launch. Going back to the original values, you decide to push out the launch and wait for the team member to come back to work. If you’d decided timeline was more important than budget, you might decide to bring in a contractor to take the team member’s place to get the work done in time for the scheduled launch.
Priorities and the product backlog
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.
Demonstrating progress
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.
In summary
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.
That’s all for this week. The next post will look at trouble-shooting some of the common challenges faced on Agile projects. Thanks for reading!
