Sprint duration, Agile, SCRUM, digital product

What is an optimal sprint duration for an Agile SCRUM development team?

Posted on Posted in Digital Skills
How to handle scope disagreement: Product owner vs. Scrum master in Agile

Before we answer this question, we need to take a step back and understand the philosophy behind the term ‘Sprint’ in an Agile methodology.

What is a Sprint? It is an iterative cycle time in which an Agile team (comprising of developers, testers, product owners, UI/UX, business analysts etc.) does software development activities. Few attributes of ‘Sprint’ are as follows:

1) It is an Agile term, specifically related to the SCRUM methodology

2) It is a set duration of cycle time i.e. once defined for the team, you shouldn’t change the duration

3) It is the base unit for doing any planning, forecast, velocity calculation for that Agile team

4) It could be of different duration for different teams in the same organisation, depending upon the need

5) The duration starts on a weekday and ends on a weekday

6) The last day of the Sprint is usually used to perform various Agile-SCRUM ceremonies like Sprint review, Demo, Sprint retrospective, and Sprint planning (for the next sprint). Some people would believe that the sprint planning should happen on the 1st day of the new sprint, however, I would advise doing it as the last activity of the current sprint, so that when the sprint starts, the work starts without wasting any time of that day.

Now, based on these characteristics, we under that the philosophy behind the ‘Sprint’ is to have a time boxed approach to define a goal, and deliver it, so that you have built something of value. This offers flexibility to change any goals (if needed) between sprints and also builds momentum, as you see a product getting built in that duration. Now, depending upon the need for flexibility, and review of the product development, the duration is chosen by the team. The duration could be either of these:

1 week – Too short to start, finish, review & demo. But is useful if you have very less idea of what needs to be done. Hence, such short duration allows for changing sprint goals on a weekly basis.

2 weeks – The most popular, and probably the most effective time slot, that allows for enough time to get all important things done, along with SCRUM ceremonies.

3 weeks – The least popular, most probably because of its ‘odd’ number.

4weeks – It is used in cases where you have an idea of what needs to be developed, however, the size of activity (e.g. research, spike, technical analysis) is so huge that there won’t be any tangible work accomplished in a smaller duration. Also, the nature of tasks is such that it cannot be broken down into any smaller chunks. So, in order to have a functioning product feature to be developed, it needs at least 4 weeks. It’s like saying – if you need to bake cakes one after the another using a single oven, you need to allow a 1-hour cycle – anything less wouldn’t give you a proper edible cake.

So, deepening upon the nature of work, the product you are building, the phase of project you are in, you can choose the Sprint duration.

If you have any question on digital product management – be it related to career, expertise, skills, projects, or ‘How to’ stuff, drop me a line at: support@myjobmyrules.com.

I would be happy to help.

FREE DIGITAL SKILLS REPORT

Digital Skills Mastery 2018

How to Win Graduate Job Roles with 7 Digital Skills?

Leave a Reply

Your email address will not be published. Required fields are marked *

*