Keeping stakeholders in the loop on sprint progress is a very important part of a product owner’s job. That said, keeping stakeholders up-to-date should take the least amount of time possible so that you have time to do the actual work of product management. I like to take a proactive approach to stakeholder updating, so that I am rarely in a position of having to react to requests for updates unexpectedly. Below are some tactics I use for simple, easy stakeholder communication to build trust as a product manager.
Make yourself an update schedule
I have a recurring schedule set up in my favourite productivity app, Todoist, with all of my sprintly tasks. This includes the following updates to stakeholders
- Communicate sprint plan publicly. For me this means posting in our scrum team’s public Slack channel with a link to our team’s wiki page with a very short summary, in layperson’s terms, of what tickets we are pulling into sprint.
- Communicate more sprint plan details to specific stakeholders. I don’t do this every sprint, but if we have particularly complex, urgent or changeable work going on, I like to add a private update to the internal stakeholders that are specifically assigned to our scrum team to add a bit more context to the public update.
- Send a mid-sprint update to specific internal stakeholders. Most sprints, I like to send a mid-sprint update to the internal stakeholders that are assigned to our team to let them know if we are tracking towards meeting our sprint goal and burning down sprint. This update can also include things we may have pulled into sprint. The main objective is to ensure no one is completely surprised when sprint review rolls around.
Communicate the unexpected
The whole point of agile is to be able to pivot quickly when you need to. For us that can include, scope changes, urgent bugs and the need to move a sprint ceremony for whatever reason. When these things pop up, I like to put a message in our public channel letting stakeholders know what happened and why we are changing course during sprint. These changes don’t necessarily affect our stakeholders directly but letting them know what’s going on helps build trust.
In the case ongoing issues (i.e. things that require a certain amount of investigation and work to resolve) that have high interest from stakeholders and leadership within your organization, it can be helpful to create an internally accessible document with a log of what has been done or has changed each day. Posting this and updating stakeholders and leadership periodically is a great trust-building step, but having a document open and updated at all times goes a very long way to minimizing anxiety about bigger issues.
Use sprint review for more than reviewing your sprint
Sprint review is meant as a time to review the work you’ve done that sprint. When I first started as a product manager, I thought that meant just reviewing the work the engineers did. Now we use it as a time to discuss the discovery we are working on outside of the engineers’ work, so that we can air any uncertainty and keep our stakeholders up-to-date on the work we have upcoming. It’s a great time to discuss questions of design, scope and priorities, as well as what was built in the last two weeks.
We also like to revisit past work in sprint review. Revisiting previous work and how successful (or not) it was helps us determine what our next iteration or step will look like. Doing this fairly frequently means that stakeholders have a good picture of why we are iterating on something, when that comes up.
Keep your backlog up-to-date
Many of us product managers are guilty of having unwieldy backlogs that become a dumping ground of ideas and “things we don’t want to forget.” I found that the best way around this was to choose a Resolution reason (in Jira) that I could filter these tickets on so that we wouldn’t “forget” anything. We also supplemented this with a team spreadsheet to capture ideas before they get on the backlog. I also have a personal list (in Todoist, of course) of tickets that I know I will need to write depending on certain circumstances. I have also become ruthless about closing things in our backlog that we definitely won’t do in the next six months.
Having a well-culled backlog gives your stakeholders a clear idea of what you are ACTUALLY going to work on.
Kate Moore Hermes 