Agile Software Development

Scrum is an agile software development process with a high focus on the project management level. It has a concept of a sprint review in the end of the iterations, where the product backlog items taken into sprint (and possibly the whole sprint) are accepted or rejected. It is possible and even recommended to accept or pre-accept some items already during the iteration, but it is not mandatory and is not always possible.

During sprint review Product Owner indeed can reject the content, because the team got him wrong, perceived quality is low, some old features got broken or team simply did not have enough time to finish everything it was hoping to deliver. Then what does the rejection mean? Isn't it a bit too naive to expect the people disappointed by rejection deliver better during the next sprint? Isn't it easier just to add some "fix tasks" to the backlog?

Predictability

The main point of accepting or rejecting content is about improving the level of predictability in the speed of delivering the business value. The only thing the rejection really means is the public acknowledgment of low and/or heavily variating velocity. If the team cannot release that many items per sprint, than it cannot do. If the team cannot release anything in one sprint (e.g. because it always needs two sprints to release anything), than it cannot release anything in one sprint. Armed with the good understanding of the usual team velocity, Product Owner and possible the team can be able to correct their plans: delay the release date, cut some content off, try improving the development process and so forth.

Scrum is not a set of answers for the problem. It is rather a tool for making the development issues visible clearly and early. Then it is up to the people to try solving the problem or not.

Photo courtesy of echiner1 @ Flickr