Perfect Sprints for CRM Projects


A sprint is a time-boxed iteration of software development during which we analyse, design, develop and test working CRM software based on the highest priority items in the product backlog.

How long is a sprint?

In Scrum, sprints can be between one week and one month long.

In the Customer Agility framework, I recommend a two-week sprint for CRM projects. Two weeks is enough time to get enough valuable features developed, but not too long that we miss out on frequent feedback.

Starting a sprint every other week seems to fit most stakeholders' schedules. A two-week cadence seems to feel right for a lot of people.

Use one-week sprints with caution. If you're running one-week sprints, you'll need to run your sprint events efficiently so that they don't consume too much of your sprint. You can't afford an all-day sprint planning meeting in a one-week sprint.

Three-week or four-week sprints can be used for much larger projects when you are working with large teams. But longer sprint cycles means more time between feedback sessions so use with caution.

When should a sprint start?

I recommend starting a sprint with a sprint planning workshop scheduled for a mid-week afternoon. We finish that sprint with a morning sprint review meeting two weeks later. I run them as back-to-back meetings with a lunch break and the retrospective workshop in between.

Why start mid-week? Starting a sprint on a Monday is frequently disrupted. Public holidays often occur on Monday in many other countries or team members like to take Mondays as time-off. Monday sprints can also encourage some weekend overtime to finish a feature. Hardly anyone spends the weekend working when your sprints end in the middle of the week.

Can I use Sprint 0 to launch my project?

Some teams like to launch their project with a "Sprint 0" (Sprint Zero). They use this period to run some workshops and prepare the initial product backlog. Some teams also like to use Sprint 0 to get set up: provision the CRM development instance, prepare their development tools and their shared project workspace.

These preparatory activities all need to get done. But let's not confuse prep work with delivering value. A sprint needs to deliver CRM software. I recommend calling your sprint 0 a planning, preparation or initiation phase and then starting sprint 1 once you're ready to start delivering stories.

Can I change the sprint length?

At Advantage Sales & Marketing we changed the sprint duration from two weeks to three after about a year. The team seemed to prefer the three-week cadence, but I missed the regularity of sprint reviews every other week.

So it's possible to change the sprint length, but I would not recommend it. The biggest downside is that changing the sprint length throws your cadence out of whack. Your historical velocity becomes meaningless and other metrics are harder to track too.

Should a sprint ever be extended or aborted?

A sprint is a time-box and it can't be extended. Even when you just need a few extra days to finish a couple of big stories or there was a public holiday for two days in the middle of the sprint. Stick to a regular cadence.

Occasionally, you might need to abort a sprint. I used a one-week sprint cadence on a recent project that was four weeks long. But we had to abort sprint 2 because the product owner couldn't match the team's pace. Towards the end of sprint 2, we still couldn't start half the stories. So we paused the project for a week to give the product owner some time to refine some of the stories. We resorted to stretching the same effort over two-week sprints giving the product owner time to commit to the sprint events and still perform her marketing job.

Your sprint experience

I'd love to hear about your experience working with different length sprints in your CRM projects. What's length worked well and what didn't? Have you ever changed the regular sprint duration in a project or had to abort a sprint? Leave me a comment below.