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