Let’s be honest with ourselves for a minute –
No matter how much time we spend thinking – no matter how precise our notations – two things are always going to happen:
- Different team members will understand user stories in different ways.
- As we start to see the first versions of things come to life, we’re going to re-think some of our earlier decisions.
These two natural tendencies are as much a blessing as a frustration – it is the diversity of understanding and the speed that we can bring things to reality that help us create the best products we can. How do we leverage the strengths of these tendencies? By getting tactical about our communication!
In this article, I’ll cover how to give effective feedback to your development team using some helpful tools for different platforms. I’ll cover:
- When to give feedback
- Giving feedback on computer screens (web pages, computer applications, etc…) using “Snag-It”
- Giving feedback for Mobile screens (phone apps or web pages), using SnagIt and Telecine
- Writing good feedback to give to the developers.
The first step is trust.
Unfortunately, some dev teams are a bit reluctant to show the PO work in progress because they’ve been abused by stakeholders in the past. The first step toward a healthy dialog is to help the dev team trust you. Here are a few things that will help:
1. Make it clear: You’re here to answer questions and check implementation, not progress.
Make it clear that these are not “progress checks,” and that you’re not here to check the team’s performance. Checking things and having discussions is a normal part of the development process, and should feel informal. The most important thing is that the team feels like the PO is an accessible member of the team, not a stakeholder to be satisfied.
2. As much as possible, work to fit into the team’s cadence,
Your team has a rhythm and disrupting it is not going to help their performance. Work with your development team to agree on the best way to engage that fits their existing process. Over time, of course, you may ask the team to change, but showing a willingness to fit into the team’s cadence will increase their willingness to communicate often.
3. Schedule Time for Feedback
You can probably give most feedback asynchronously, but don’t procrastinate on feedback just because there isn’t a meeting planned! I’ve found it is best to set aside a certain time every day to check in with the dev team’s questions (I even have an alarm set on my phone!) This is important for two reasons:
1. Avoid becoming a Bottleneck
In a given sprint, the team will be working on multiple user stories. When a developer runs into a problem with one, it is easy enough (usually) to switch over and work on a different story while she’s waiting for an answer. If too many questions pile up all at once, though, the PO will become a bottle neck – the team will run out of things to work on. Productivity drops, and frustration rises.
2. Avoid procrastination
By checking in often, the task of answering questions stays manageable. When things pile up, we’re more likely to procrastinate dealing with them. For my team’s one-month sprints, it usually only takes me 30 minutes or less to assess the day’s issues and make a plan for how to solve them. Simple mis-communications can be solved with a quick note and some annotations using SnagIt. For complex things, I can put time on my calendar to do some more research, schedule a quick discussion with a dev, or meet with an outside stakeholder to work toward resolution.
Next: Give good feedback without wasting time
You’ve gained the team’s trust (or, at least, you’re working on it), you know what to give feedback on, and you’ve set aside a little bit of time. On the next page I have some tips for giving good feedback quickly.