Why use iterations in Scrum?

Question

I am a Scrum Master in a 7 person team. We currently use one-week iterations for our sprints.

I find that sprint planning overhead is huge (2 hours each week for entire team), and not nearly as productive as it should be. Our team members do not care what each task costs, they rely on one or two people with context to provide the estimates. It seems team-wide sprint planning is meaningless.

Additionally, there has never been a sprint where we successfully completed ALL planned tasks. We always complete most of them, but there are always a few left over for the next sprint. It seems the time-boxed idea is not working at all, as we are never able to fully deliver. Maybe it has something to do with only two people contributing to estimates, but I don't see the team completing all features even if everyone contributes to the estimates.

I know there are literally tons of books and papers that describe how wonderful iterative and incremental development are, but it just doesn't seem to bring enough goodness to our team.

So my question is, how valuable exactly is it to keep a time-boxed iteration? If we just let one or two dedicated people maintain a strictly prioritized list and showcase deliverables as necessary, what's the downside of it?

Answer 1

TL; DR

You actually have two questions. One is about time-boxing, and the other is about estimation.

Time-boxing and estimation are the very essence of Scrum. If you aren't adapting those two practices for your team, whatever you're doing isn't really Scrum.

Tools and Practices Aren't Silver Bullets

[Incremental development] just doesn't seem to bring enough goodness to our team.

Time-boxing is a tool. It is not a goal in itself, it is a means to an end. Objectives for time-boxing include:

1. Composing more granular user stories.
2. Applying implicit work-in-progress limits.
3. Improving the accuracy of estimation.
4. Developing a predictable cadence within the project.

Time-Boxes: Essential to Scrum

[H]ow valuable exactly is it to keep a timeboxed iteration?

Time-boxing is essential to the framework. It ensures that work is properly sized, that features are scheduled based on team capacity, and that the project has a tight feedback loop for its deliverables.

The length of the time-boxes can be adjusted, but you can't do without them. In fact, sprint length is one of the most effective control dials for a project.

• Shorter sprints...

  • accelerate the feedback loop.
  • increase process overhead.
  • reduce implicit WIP limits.
  • reduce maximum work-unit size.
  • reduce cycle times for properly-sized work units.

• Longer sprints...

  • reduce process overhead.
  • increase maximum work-unit size.
  • usually increase the effort required for feature integration.
  • increase time available for implementing process controls at the cost of higher cycle times.

You have to find the optimal sprint length for your team. It is very likely that one-week sprints are too short for your organizational requirements.

Time-Boxing and Estimation Work Hand-in-Hand

[T]here has never been a sprint where we successfully complete ALL planned tasks. We always complete most of them, but there will always be a few left into the next sprint. Maybe it has something to do with only 2 people are contributing to estimate[s.]

I'm going to make a few assumptions here. First, you don't have sufficient team buy-in or participation to rely on your estimates, and so you discount the value of estimating. Second, because your work is improperly estimated, you are pulling more work into each sprint than your team capacity can support.

All teams occasionally miss commitment targets, but routinely failing to meet them is a sign of a fundamental process problem. In your case, this is likely due to improper iteration length, inaccurate story estimates, or stories being shoveled into each sprint from outside the team without regard for WIP limits or team capacity.

Possible Solutions

Estimation

You can improve your team's estimations over time by using some widely-accepted practices. Some of these practices include:

1. A formal Sprint Planning session where the whole team participates.
2. Planning Poker to encourage unanchored estimates and prompt discussion about variance in estimates.
3. Sprint Retrospectives where estimates can be reviewed to identify lessons learned about the team's estimating process.
4. Promoting collective ownership or swarming instead of assigning stories to individual team members.

Team Capacity

You can improve your team's velocity and story completion rate by following the framework's guidelines. Best practices include:

1. Adjusting sprint length to the optimal size for your typical user story.
2. Revising your velocity expectations downwards when commitment targets are not met.
3. Limiting stories accepted into each sprint the lower end of your predicted velocity range.
4. Working with the Product Owner to decompose user stories that don't fit within a single sprint.

See Also

• Related answer about how sprint length can impact process overhead.
• Related answer that discusses swarming and WIP limits.

Answer 2

I think you should be asking "Why is the team not sufficiently engaged to provide estimates?"

This may help you get to the root of your problems, which I suspect is more likely a leadership issue at some level than one of process. You will need to step up and try to mitigate these effects by working to engage the entire team. Sit down with the team members who don't provide estimates and - in as positive and non-confrontational way as you can - find out why. Take this information and work to re-engage the team so that they are not only contributing to generating estimates but are also taking ownership.

As for the more symptomatic issue of timeboxes, if you don't set a deadline for a task it will never get done when you need it. One can argue all day about how long a timebox should be for a particular project or iteration or deliverable or action item, but I don't think the basic need for setting limits on how long something should take is debatable.

Answer 3

It seems to me you are mixing two things - prioritization of the tasks that will go into next Sprint, and task estimation. Project stakeholders should prioritize tasks, and the team estimates how much tasks will fit into next sprint (usually 1-2wks). Timeboxed sprints are good for setting proper expectation with Client, and good for deployment iterations (only ready and tested code goes to staging deployment every week).

If you're starting sprints on Mondays, on Tuesday of the previous week arrange session with project stakeholder (Client) to create prioritized list of items to be done next week. It may not go fast, but say, on Wednesday client will send you the list. On Thursday invite 3-4 qualified developers to a Planning Poker session (not worth to take all team to estimation session.) Estimate every item in the list in Story Points. Split large features into smaller ones. See how many Story Points were done previously (previous Sprints), and cut your task list down to about same size of Story Points. If there's questions, clarify them with the Client and Developers on Friday. Email the shortlist to the Client to set correct expectations. Start working on the Sprint on Monday - this short list is likely to be finished on Sprint.

Probably not every sprint will match your estimates exactly, that's just impossible to achieve every time, however after 10 sprints, you'll likely to be more efficient at estimating.

Answer 4

Timeboxed iterations are good for establishing velocity. It will take several iterations, but at some point you will be able to say that the team can get done, say 15 to 20 points in a one week iteration.

The downside of not establishing a rough velocity is that you cannot do any planning. If your backlog is, say 300 points, and a new initiative needs to be brought in, you will not be able to make a judgement call whether the priority can be rearranged or you need to hire more people or outsource the work.

Answer 5

If we just let one or two dedicated people maintain a strictly prioritized list and showcase deliverables as necessary, what's the downside of it?

The downside: When there are no specific deadlines, tasks often take longer than they should.

More specifically: "Work expands so as to fill the time available for its completion." -- Parkinson's law

If that time is infinite (no deadline), well... you can see where that leads.

...how valuable exactly is it to keep a time-boxed iteration?

In my experience, it's pretty valuable.

I don't see the team completing all features even if everyone contributes to the estimates.

This is a totally separate problem you may want edit it out and submit as a separate question.

But I certainly wouldn't advise moving away from timeboxed iterations to address a problem with estimation and delivery.

Answer 6

There are some valuable suggestions in other answers but I thought I'd share what my team has been doing.

For quite a while now, we've not done sprint planning or story point estimation.

The important thing is that you look carefully at why you do those things and replace them with something else that gives you the same result, in a way that works better for your team.

For my team, we decided that Sprint Planning was done for three reasons:

1. To give the PO an idea of what we would complete in that sprint, so he could communicate progress to other parties.
2. To give the team an opportunity to confirm the intent of a story with the PO and discuss any unclear acceptance criteria.
3. To check that, given what we have learnt since we originally estimated a story, the points given to it still sounded right and re-estimate if needed.

Secondly, we decided that estimation (which we did in a separate session) is valuable for us, again for three reasons:

1. To communicate a story to the team and allow the team to question the PO.
2. To force a conversation about the complexity and risks involved in a story.
3. To ensure that a story is not too big to be worked on in a sprint.

So, we looked at ways we could generate the same outcomes in different ways, stopped doing planning and introduced:

Backlog sessions - This is a 30 min slot each day (although only used on an 'as needed' basis) where the Product Owner introduces upcoming stories to the team. We then discuss them at a high level, identify where we may need spike or a technical design session to elaborate and decide if it is of a size we're willing to accept or if it needs breaking up (rule of thumb is do we think we can do it in a week). This replaces points 4, 5 and 6.

Story Huddles - This takes place as a story is starting, usually between the dev pain, BA, QA and PO. It's an opportunity to make sure we've captured acceptance criteria, have an idea of the tests we need to write and we can split a story up if we start to think it's too big to be done as one. This replaces points 2 and 3.

Cycle time as a metric - Rather than measuring velocity, we just measure how long it takes for the average story to be completed. Monitoring this over time helps us identify when our story size/complexity is creeping up and also gives the PO scheduling information (if I have 5 things I want done and cycle time is 4 days, I should have them all in 20 days time). This replaces point 1.

This works for us but I advise you go through the same process as we did and examine what value you do get out of your current process before making any changes.