FEEDBACK IN SCRUM

 FEEDBACK IN SCRUM

I learned the importance of rapid feedback as a swimmer in high school and college. Like most people, I started my swimming career in the pool. If you head off course in a pool, you get instant feedback from bumping into a lane line.

Eventually I tired of swimming laps in a pool and moved to open-water swimming. Instead of flipping direction every 25 meters, open water swimmers often swim multiple miles between two or more points such as across a bay. When swimming in the ocean there are no lane lines to keep you on course. It’s up to you to set a path. If you deviate too much, you’ll end up swimming much farther than you intended. Swimmers’ main strategy for staying on course is to periodically lift their head slightly to confirm the path.

How often to do this is key. Do it too often and it’s tiring; don’t do it often enough and you risk going off course. The more often a swimmer gets feedback, the less they veer off course.

It is exactly the same with agile teams. The short feedback loops in Scrum give teams multiple opportunities to inspect and adapt, ensuring that products are headed in the right direction.

Increasing and Improving Feedback

Let’s look at a few things you can do to improve the timing and usefulness of feedback.

First, if you aren’t already holding a review meeting at the end of each iteration, now’s the time to start. Some teams think they are saving time by conducting sprint reviews less frequently. This creates problems because a small misunderstanding in one iteration can compound into a much bigger issue a few iterations later.

With today’s globally distributed workforces, you should also consider making a recording to share with those who cannot participate live in the review meeting. In some cases you can record the actual review meeting. In most cases, though, you’ll be better served by creating a narrated screen recording that demonstrates the new functionality.

Creating a screen recording like this can be very quick if you do it after each iteration. After all, there isn’t usually that much functionally added. A link to the screen recording can be shared with everyone or just those who could not participate live. You can request people send you feedback directly or allow people to leave feedback on the page with the video.

In addition to an iteration review meeting, you may want to consider a series of one-at-a-time feature reviews. As each feature is implemented, show it to the small number of stakeholders or users who requested it and solicit their feedback right then.

Not everyone who participates in an end-of-iteration review needs to offer feedback on every feature. Doing one-at-a-time reviews with select audiences can often generate higher quality feedback earlier.

When soliciting feedback, ask a variety of questions. In many reviews the only question asked is “Whaddaya think?” That often generates comments such as “I like it” that are hard to act on.

I like a lot of things—but a lot of things could be a little bit better. I like the tacos from my nearby taco truck, but they’d be a bit better if they were spicier.

Asking “Whaddaya think” usually fails to get the detailed feedback we need. Consider asking more targeted questions instead, such as:

  • Is there anything we overlooked that users might want to do here?
  • Would any of our user types find this confusing?
  • Do you see anything here we could leave out?

Drill down further: When asking questions such as these, consider asking them of specific individuals rather than the full group. Be open, of course, to anyone’s comment—but directing questions to a particular participant reduces awkward silences and can sometimes lead to better conversations.

Timing of reviews is also critical. Try to demonstrate and get feedback on features well before they are 100% done. Suppose you are developing a new capability that can only be delivered after ten product backlog items have been completed. Don’t wait until the tenth and final backlog item is done before soliciting feedback.

Whenever possible, strive to get feedback directly from users rather than from stakeholders commenting on their behalf. For internally used products, this can be as simple as inviting users to participate in reviews. For commercial products you might need to create a public forum on which users can share feedback.

Finally, be sure the team includes time in their plans to act on the feedback. Nothing is more disheartening to stakeholders and users than to provide feedback only to see it ignored.

A Recap

Here’s a recap of the seven things you can do to improve the quality and timeliness of feedback:

  1. Start doing iteration review meetings if you aren’t already.
  2. Send a screen recording to people who could not participate.
  3. Do one-at-a-time feature reviews for those who requested a feature.
  4. Ask more targeted questions, of specific individuals.
  5. Solicit feedback on partial solutions rather than waiting until all product backlog items are complete.
  6. Seek feedback from users instead of stakeholders commenting on users’ behalf.
  7. Leave time for the team to act on the feedback.

Getting rapid and frequent feedback enables teams to build products that meet users' needs. A team that gets feedback too infrequently should not be surprised when they veer as off-course as a swimmer who fails to check that they’re not nearing Niagara Falls.

 

 

Acknowledgements

Scrum.Org blogs


 

Comments

Post a Comment

Popular

Science of Influence

One of the traits that Project Managers or any Leader needs to develop is the ability to influence. Every project ecosystem consists of Stakeholders, internal and external. These include your own team members. The ability of a Project Manager to influence these Stakeholders will ensure that the project is in control. Dr. Robert Cialdini has developed 7 principles of influence which can be used by Leaders to influence others. 1.  Reciprocity :  When you do people a favour, they tend to respond in a manner you want them to. However, there are some points to note. - I t’s not about what is given, but HOW AND WHEN IT IS GIVEN . Be the first to give the favour. - Let it be personalized and unexpected. Tell them ‘ I am doing this only for you ’. Suppose, you have done a favour to a person and he/she says ‘Thank you’. What is your response? Many of us say, ‘Its okay’, ‘It was my duty’ etc. Some rare person may say ‘Now you also owe me a favour’.  Instead use this principle Respo...
Read more

CONFLICTS in Teams - How to address them?

Conflict on teams is inevitable. But here’s the real question: does it need to be resolved? Not always. In fact, the type of conflict matters just as much as how you address it. Some conflicts demand immediate resolution, while others can be channelled into creativity and progress. Knowing the difference is critical to leading a team effectively. At its core, conflict on teams falls into two categories: personal conflict and task-focused conflict. Personal conflict is what most of us think of first—tensions that get personal, unkind remarks, or behaviours that erode respect. Left unaddressed, this type of conflict undermines trust and productivity. Task-focused conflict, however, is entirely different. This is the natural tension that arises from diverse ideas and perspectives. It’s not a problem to be solved; it’s a tool to be harnessed. Handled well, task-focused conflict can propel a team forward. Let’s look at both in depth—how to resolve personal conflict and how to channel ...
Read more

Application of Scrum Values

The essence of Scrum are the 5 values. A Scrum-Agile project will not be successful unless these values are demonstrated in every event, while preparing every artefact and while performing any role. In fact, these values can be demonstrated in any environment to reap benefits. Here are 10 practical instances for each Scrum value that any team can demonstrate: COMMITMENT Team members dedicate themselves to achieving the team's goals and doing their best work. They commit to the sprint goals and support each other in meeting those commitments. Team commits to delivering specific user stories in the sprint backlog, even when facing technical challenges or scope creep requests from stakeholders. Team members commit to rotating on-call duties to ensure continuous support for critical production systems across different time zones. When a legacy system needs modernization, team members commit to learning new frameworks or cloud technologies requ...
Read more