Scrum is the adaptive and flexible software development methodology. The possibility to adjust it according to the team preferences and organizational culture make Scrum implementations look differently across the organization. Some teams like packing the estimation session into a separate day, some like doing a little bit of estimation during every sprint planning; some teams have 5 minutes long sprint reviews, some have to make their reviews day long in order to let all the stakeholders express their opinions.
Scrum process schedule can and should be adjusted according to the retrospectives held. Therefore, it is not that important to start with the perfect schedule, it will anyway be adjusted. However, it can save some time if we start with something that works for many teams out there. Here a couple of more-or-less standards schedules to start with.
30 calendar days sprints
- Day 1. Sprint planning meeting, 1st segment - 3.5 hours
- Day 1. Sprint planning meeting, 2nd segment - 3.5 hours
- Every working day between day 1 and day 30. Daily stand-up meeting just before lunch
- Day 30. Sprint review meeting - 3.5 hours
- Day 30. Sprint retrospective meeting - 3.5 hours
14 calendar days sprints
- Day 1. Previous sprint review meeting - 2 hours
- Day 1. Previous sprint retrospective meeting - 1.5 hours
- Day 1. Sprint planning meeting, 1st segment - 2 hours
- Day 1. Sprint planning meeting, 2nd segment - 2 hours
- Every working day between day 1 and day 14. Daily stand-up meeting just before lunch
- Day 14. Sprint review meeting - 2 hours
- Day 14. Sprint retrospective meeting - 1.5 hours
What do you think about such schedules? Does it look like something that would work for your team? Is it really a good start to start with one of these schemes.
RSS feed
Comments
Looks good
Hi Artem,
This setup seems fine to me. However, it's also worth noting that can be even more flexible in defining the duration of a scrum project: typically it's worth defining the duration between 2-4 weeks. Not less, since a team cannot do much in less than 2 weeks. Not more, since we would lose the ability to react to changes quickly - don't forget one of the most important rules in scrum: never ever inject new requirements into a running sprint.
It's another topic, but still in connection with scrum: it's one thing that a team is committed to following scrum's rules, but it won't help if the customer doesn't understand/support that. It's the better case if they approve that we apply scrum framework, but it's still too bad if they don't fill in the role that scrum assigns to them: being the product owner. It's a pretty difficult situation, btw.
Tote
Art of possible
Scrum is the "Art of possible". Every team adjusts the process according to its circumstances. If team believes it can work best with 3 week iterations (though it is rarely a good choice), it can try it. I only wanted to present couple of usual "default" schedules that are good to start with.
I believe, the same goes with the customer involvement issue. If customer supports the process, it's good. If he doesn't, the team has to find out a compromise. E.g. if a customer doesn't have time for being a product owner, team can have a proxy product owner.
One-week Iterations Possible in Web Development
How to do 1 week iterations
Post new comment