How do you structure a development sprint?

Question

So I have a backlog of features and we are about to get started on a sizable project. I am working on defining the structure of our sprints and I'm interested in the communities feedback.

What I'm thinking is:

• One day sprint planning
  • Fill the backlog and figure out what each dev will go after this sprint
• Three weeks of development
  • GO! GO! GO!
• Daily stand up meeting
  • Check to see if anyone needs help or feels off track
• Two days of sprint review
  • code reviews happen here, stakeholder presentations
• One day sprint retrospective
  • what did we get done in the last sprint? how can we do better next time?

Sprints should always end on a Tuesday (to avoid too much weekend stress).

Anything else? There is obviously more to agile than this. I want to provide the team with a simple outline of how we are going to operate as we get this project started.

Answer 1

Turn off email, cell phone and instant messaging apps for core code time. 10am to 1pm, 2pm to 5pm might be good blocks for this.

Order food, drinks for team when they are in "the zone".

Cancel all other meetings for the days of, before and after the planning session and the review days.

Answer 2

I'd consider experimenting with sprints that are shorter then one month.

Personally I find one-two week iterations more effective at getting effective feedback quickly. It also prevents any issues that may be causing problems at the iteration level building up to levels that become harder to manage.

Even for the 30 day sprint - two days sounds about a day to long for the sprint review... and one day sounds about 0.5 days too long for the retrospective. I've found that if you need much more than that there have been communication problems while the iterations has been going on - so you might want to look at needing long reviews as a possible red flag.

Of course that's just been my experience - of mostly developing web apps with smallish (4-12) person teams. You're experience may vary.

That said - I'd definitely give shorter sprints a try. Like integration builds - a lot of things get easier if you do them more often.

Answer 3

• Make sure the "stand-up" remains a STAND-up. It is very easy to slide into longer and longer meetings.
• One day of sprint planning and three days at the end may be too much. Only schedule as much time as you need.
• +1 to the idea of shorter iterations. Personally, four one-week iterations within a sprint have worked well. People are great at estimating near-term tasks; past that it becomes more and more guesswork.

Answer 4

Looks like a good approach. I second what adrianh and jedidja said about possibly shorter iterations. I like 1 weekers myself. As well as better estimation, it also keeps the idea of "working software" on a much shorter cycle.

A few questions:

Why are code reviews left until the end? Either pair program, or do your reviews as you go.

Does 3 weeks of development mean "dev, test, documentation, installers, etc" ? I.e. everything you need to be truly done?

Answer 5

We structure our sprints very similar to your outline except our sprint reviews are the last day of the sprint and generally on last about an hour. The sprint review is the time where you exhibit your work to the customers and any other interested parties, not the time to do code reviews. Code reviews, if you chose to do them, should be done periodically throughout the sprint. We used to have a one hour block each week where we'd go over developer nominated code, meaning we didn't waste time reviewing every LOC written.

We also end our sprints on a Tuesday and begin on a Thursday leaving Wednesday to wrap up loose ends and tackle technical debt created during the sprint.

Answer 6

I don't recommend postponing code reviews until after the sprint, they should be an integral part of the development process. In other words, a task is not done unless the code has been reviewed (and tested, and documented, and ...).