How do you structure a development sprint? [closed]

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

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 2

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 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 ...).

Answer 7

Its important to stay away from managing for the sake of managing. SCRUM only requires 1 meeting a day, and that's a short one. Additionally, during each sprint, the only other meetings are the Spring retrospective, and the sprint planning. This allows us to implement ROWE, or a Results Oriented Work Environment. Let your developers decide How, Where, When they will do thier development. Use your daily stand-ups to track that they are doing their work. Other than that, stand back and be amazed at thier productivity.

Ideas like "turn off cell phones, turn off IM apps, etc during coding" are all bad ideas. When you hire your team, you are hiring them with confidence that they know how to do thier job correctly. If you hired them with that understanding, why would you want to constrain thier ability to get thier job done the best way they know possible? If you're using SCRUM, then each developer will have chosen the work they feel they're able to do, your job as a Scrum-Master is to remove obstacles, not create them.

Code Reviews: Absolutely necessary. Peer reviews of code are a great teaching tool for junior developers attending meetings, and for the folks having thier code reviewed.

Design Documents: I personally feel that detailed design documents covering what the developer intends to do is very important, and I also feel they are an important part of the development process. Now, this is not specifically in-line with agile development, but I personally regularly refer back to design documents created years ago to see what the original developer was thinking when they coded their modules.