In a Scrum project, should testing and peer reviews be worked into each sprint as individual tasks?

Question

This seems to be a point of contention where I work. Some complain about the lack of verification structure in Scrum projects, while Scrum purists say it's not what Scrum is about. Both sides bring up great points, but I would like to see what people outside my circle say about the subject. What are your thoughts? Why?

Answer 1

It should, because if you don't enter them explicitly as tasks, then they might not be done. As simple as that.

Answer 2

In a Scrum project, anything that needs to be done should be entered as a task.

One of the key points of Scrum is being able to accurately predict what a team can get done in a sprint. In order to do this, you must account for everything that is going to consume a developer's time.

This means that things like documentation, testing, and peer reviews must all be taken into account as tasks.

Edit: Based on Mendelt's post, I'm going to clarify things a bit.

From Wikipedia :

Product Backlog: The product backlog is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the "What" that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority (e.g. if "add spellcheck" feature is estimated at 3 days vs 3 months, that may affect the Product Owner's desire).

Sprint Backlog: The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like.

Items on the Product Backlog will not show things like documentation or testing, but the tasks on the Sprint Backlog most certainly should.

I'll give an example. Say there is a "Feature A" on the Product Backlog, and its estimated time is 1 week. On the Sprint Backlog, that might be broken up into the following tasks:

Initial design document:              4 hours  
Development of subset 1 of Feature A: 8 hours  
Peer review of subset 1 of Feature A: 2 hours  
Testing of subset 1 of Feature A:     6 hours  
Development of subset 2 of Feature A: 8 hours  
Peer review of subset 2 of Feature A: 2 hours  
Testing of subset 2 of Feature A:     6 hours  
User Documentation for Feature A:     4 hours
---------------------------------------------
Total time                           40 hours

Edit #2: The idea behind the Sprint Backlog is to be specific as humanly possible about exactly where you have to spend your time. This is why tasks cannot be more than 16 hours long and it is how you get to a point where you can be very reliable in your schedule predictions.

If you follow the Sprint Backlog guidelines religiously and make sure to include everything that you spend development time on then you will be pleasantly surprised at how accurate your scheduling can be after a few sprints of practice.

Answer 3

Think in verticals, rather than horizontal layers.

If you consider design, programming and unit testing, testing, etc as layers in a development cake, I guess you could see the features (stories) you deliver as cake slices, each consisting of a small piece of design, code, testing, performance, etc. This somehow like Pragmatic Programmer's "tracing bullets".

Answer 4

Prior to scrum, we followed the waterfall development paradigm which included code reviews prior to committing anything to version control. Since moving to scrum, we do not assign separate tasks for the code review since it's implicit in any development stories.

Answer 5

One of the key verification structures that is built into Scrum is that the product owner is responsible for accepting the stories. The team only gets credit for velocity based upon delivering business value.

A common tool for Scrum teams is to define acceptance tests for product backlog items (often these backlog items come in the form of user stories).

As part of coming together as a Scrum team you need to answer the question of what engineering practices the team is going to use to help it deliver a high quality product. Scrum by itself is quiet on these practices (I think intentionally to allow these practices to evolve over time as we learn how to do things better).

These practices may be things like unit testing, pair programming, peer review, etc. Often times these become part of the team's definition of what it means for something to be done. If a team is struggling with estimates or getting to done - it can be helpful to call them out as tasks in the sprint backlog. My recommendation is to keep the process lightweight - you don't need to call out every little thing (but you do need to account for the time it will take to do routine items in the estimates).