What To Do With Sprint Feedback

Pop quiz: You’re wrapping up your sprint review, and summarizing requests made by your customer.  Do you:

a) commit to fulfilling those requests before the end of the sprint you’re closing out,
b) commit to fulfilling those requests in the next sprint, or
c) not commit to making any changes during the sprint review?

My answer is C.  Let’s explore why C is the best answer.

Think back to when you started the sprint.  You and your team committed to your product owner a body of work to get to Done by a certain date.  You held your daily standups and you had ready access to the product owner and/or customer during the sprint.  Maybe you even had to put in some “overtime” to get things done. (more on why overtime is in quotes in a different post).

In any event: there you are, showing off the work the team accomplished, and now you have a set of feedback items to deal with.  Inevitably, some of that feedback will contain change requests.

It’s usually easy to detect change requests.  These often are prefaced with phrases like “it would be nice if” or “I’d like to see it do this.”

If the team commits during the sprint review to fulfill the requests before the end of the sprint you’re reviewing, then you’re setting yourself up for a short number of very long nights (remember: you also committed to a date at the beginning of the sprint).  You also reinforce the behavior of accepting changes at the last minute.  Not a good path to travel.

Let’s now consider committing to those requests in the next sprint (option B).  On the surface, that sounds better, but it’s only a tiny bit better.  There are reasons why your sprint reviews are separated from your sprint planning meetings.  You won’t have the right people in the room to fairly build out the workload for the next sprint, and pre-committing the latest and greatest change requests could displace other, higher-priority issues that your product owner is responsible for managing.

This brings us to C.  It should be fairly clear why C is the best choice, but if not, here’s why: It’s in the best interest of the team and the customer for the product owner to consider with equal weight the old and the new when it comes to managing product backlog.

It’s in the best interest of the team because you really do need the opinion of the developer(s) that may not be participating in the sprint review for whatever reason, and it’s unlikely you will know enough about these new requests to assign story points on the spot.  You certainly won’t have enough data to make a rational time estimate that feeds the sprint backlog.

Option C is also in the best interest of the customer because she is also not thinking about the backlog, which is out-of-sight-out-of-mind in comparison to that shiny new GUI she is drooling over in the sprint review.  Deferring commitment, even if just until the very next sprint planning session, helps mitigate buyer’s remorse on the part of the customer.

The sprint review is the ceremonial, if not technically the end of the sprint, because it’s near or at the end of the sprint and because the team has met all of their acceptance criteria that they set out to meet at the kickoff.  Be careful to not sabotage the team and its velocity, or otherwise move the finish line, just for the sake of making fast promises to an eager customer.

This entry was posted in Software and tagged , . Bookmark the permalink.