Ever been struck for time during a project? Is your sprint running close to the wire? Ever thought about cutting out those reviews and retrospectives to gain a handful of development hours back?

WELL DON’T!

Reviews and retrospectives are an integral part of the scrum process and aren’t there just for the sake of it. I’ve seen a few teams now that are struggling for time during a sprint cut the review and or retrospective. I know of one team who because of “code commitments” managed to not deliver a review session for several sprints in a row. What happened? The product owner got upset. “I don’t know what they are doing”, “I don’t know what the application looks like”, “Who knows what’s going?” are some of the things he said in frustration and I’m sure the teams developers felt pretty much the same frustration. You see as humans we need closure, we like to close off a sprint, tidy up and move on. If we have had a good sprint, the team will want to show off and demo the product. If it was a bad sprint, then draw a line under it and move on.

Reviews are completed for the following reasons:

• To demonstrate the product to customer/product owner and re-assure them of progress
• To elicit feedback from the customer for future iterations
• To provide closure to all involved, whether it be a good or bad sprint.

They are not an optional part of scrum. I’ve covered the value of retrospectives in a previous blog post. Sprint Retrospectives and their Formats or "When Retrospectives Go Wrong!