Dynamic length of sprints in Scrum

Do you measure the velocity of your team? And if so, how do you do this?

By 'dynamic sprint length', do you mean that there is a lot of variation in the sprint duration? So the first sprint may take 2 weeks, the second may take 3 weeks and the third may take 1 week? Or are we talking about much shorter or much longer sprints?

Is your team capable of delivering the desired functionality within your (dynamic) sprints? Or are they often done well before the end or is there a lot of unfinished work?

Regular timeboxed delivery is one of the core disciplines of Scrum, which relies on predictable inspect and adapt cycles. This means that Sprints have to be of a fixed length. There is skill involved in negotiating a meaningful increment of value within a fixed time period, but it is an important skill.to have.

Some agile methods do away with Sprints entirely, and just have a continuous flow of delivery. That's typical of a Lean Kanban way of working, and "Business as Usual" changes. It sounds like you're doing project work though, in which case you'd be better off applying Scrum fully.

As mentioned earlier, it would be difficult to measure your team's velocity with variable sprint lengths. It also makes it more tempting to extend the length of the sprint if it looks like you took on too much work in the sprint rather than acknowledging unfinished work, taking the hit on velocity, finishing the work in the next sprint and adjusting how much work you are including in future sprints. In my experience teams get into a rhythm with sprints, and I think this rhythm would be disrupted or never found with dynamic lengths. Even more troubling would be if it were a team that was new to scrum coming from something more "waterfallish" -- I could see teams slowly increasing the length of sprints until they end up with one long sprint (waterfall). I know you said you were obeying the min / max length but I would still worry if the team is new to scrum.

step by step

- You always can measure the team velocity just doing with a percentile number (for example, total points in sprint / finished points), so, the measurement is not a problem.
- The difference betweem sprints is really short. Spoke about 3 o 4 weeks Sprint. At least, in special moments, 5 weeks.
- The team works perfectly with this aproximation. I do not know why the dynamic lenght of the sprint would have to impact in the delivering capacity of the team.

The theory is simple: In the Sprint Planning Meeting the team (Product Owner) decides which stories include in the Sprint; later the team estimates the effort and at the end we sum all the points inside the Sprint to "calculate" the Sprint length.

There's a saying in project management -- "there are three variables, resources, scope, and schedule -- you can pick two." In scrum your resources (team) and schedule (sprint length) are the things you're picking and your scope (amount of work) is determined by those. What you're doing is picking resources and scope and having the schedule vary. Is it acceptable? Sure, if the work gets done, and the team and customer are comfortable with it. I would still caution against extending the length of the sprint during the sprint. If that's not the case and isn't happening, then it's not an issue.

My point is - can't we isolate the product release from the sprint duration. Let team work on a fixed duration sprint and marking backlog items as Done. The release manager or product manager can discuss and decide at what point (even during the sprint) they would like to release the next increment of the product. This is based on the assumption -

1. You have an integrated environment which should have release-able product deployed during the sprint.
2. The deployment process is automated

Changing the sprint duration is more difficult if you have multiple teams working on the same product.

Hi Ztere0,

I must admit this is actual the first time that I’ve seen a team deliberately keeping their Sprint dynamic to delight the PO. Kind of interesting though :-)
Personally I wouldn’t dare to apply this kind of change with my teams due to the following reasons:
I want the PO to think in terms of Minimum Market Features. In other words, what’s minimum needed to improve the time-to-market. When dynamic sprints are applied, I can imagine that the PO is (at first) a very happy person because all the “urgent” stories will be included in the sprint. This can lead to a long(er) sprint which implicitly means that the team will have to wait longer for feedback.

Another important thing is responsibility. The moment the development team apply dynamic sprint lengths, the team is implicitly telling the PO that they can finish all the stories because that’s the reason why we shorten or extended our length. Perhaps the PO would be less happy if the team calculated that it would take 5 weeks and didn’t delivered due to unexpected issues or worst did delivered but not according to expectations. The other way around is a bit different though. The team tells the PO that they have a fix length, so the PO should think wisely about splitting up items and prioritizing them, making them more manageable and predictable. When the team doesn’t deliver, they will at least have their feedback on the stories that are finished.

Cheers, Chee-Hong

True........Scrum sprints of varying length are a better and wiser way to execute scrum. It should depend on the type of work to be completed in that particular sprint.

http://www.agiledistributed.com/

Hi Ztere0,

It may work for you but it is definitely not Scrum. From Scrum Guide:

Sprints have consistent durations throughout a development effort.

As others have said, you want to be able to forecast your development effort for the next Sprint, if you do not have a consistent sprint length then you do not have a reliable data that you can use for forecasting.

Ask yourself why you need to change the rule, are there problems you are covering up?

Keep working on it. Good luck!

Hello Joshua,

In my team perfectly can forecast the sprints. All the "must" that people here speak about to use fixed sprint length are based in be more "predectible" and to be measurable, but I know that those points are not a problem in dynamic length sprints (I do not why some people assume both points as a real truth)

In my experience I can ensure that using dynamic length you can be at least equally predictable and measurable that using fixed length.

best regards,

Sounds more like waterfall than Scrum. It's definitely not Scrum.

HI,
In my experience this is usually a reaction to not having the Product Backlog in a well groomed enough state to allow for good Sprint Planning.
The cadence that you build up with having a fixed Sprint length allows the capability of having a stable velocity.The stable velocity allow the preparation of a product roadmap.

If you vary the sprint length the result is an inconsistent velocity.

Team velocity is based on a certain timeboxed event. Why should this always have to be the end of a formal Sprint? Why can't you have an ongoing process (like kanban) but for example measure your velocity based on an agreed timebox?

@P.Ross
Within the Scrum framework the fixed Sprint length is used to provide stability and predictability. This is a key aspect of the Scrum framework.
If you don't have any Sprint Timeboxes - it is not Scrum. This is not a good or bad thing, it just is.
The lean metric that you would use to measure the unconstrained system is cycle time, and that would have more relevance than velocity.

The point is if you are doing Scrum the Sprint length is static, and deliberately changed at Sprint boundaries with the intent to improve team performance. It is not varied within the Sprint.

Ztere0,

If it works for you, great. Let not the fact that it is not an acceptable scrum practice (which it isn't, BTW) deter you. I believe there are always special cases and special teams which need a bending of rules. At the end of the day, I presume you aren't implementing Scrum for the sake of Scrum, and also that you have sufficiently analyzed and accepted the trade-offs.

Consider a similar scrum rule: a Scrum Master should not be the Product Owner as well. But in his book, Succeeding with Agile, Mike Cohn mentions a couple of teams which broke this rule, yet were very successful with Scrum. He also says that it is not for everyone: the person playing that role has to have exceptional maturity to be able to pull it off.

Here's another one. A "goto" is supposedly a no-no in C programming, yet, I have seen some code which could not have been written as elegantly without using it. I wouldn't advocate using goto in C to a novice programmer. But if a master programmer uses a goto in a situation that he/she can justify, I don't see any wrong. In the same vein, I wouldn't risk dynamic lengths until I have mastered Scrum.

We have always done an agile-scrum hybrid at the Software companies where I have worked, so I'm not commenting on Scrum as somebody who has practiced it strictly. Our hybrids have been very successful (Henry Schein Medical) and passable (recent job). At a recent job, we discussed trying two 1-week Sprints instead of our normal 2-week Sprint.
Cons in this thread and my Responses
The Scrum Team is letting dates slip at the end of the Sprint because they didn't get done. --> We are not doing variable length sprints to get less done, but to get releases to Customers FASTER.
Scrum says so (or “it's not scrum” rule). --> Some would argue that you cannot change your Sprint length during the Sprint, but are allowed to change from a 2-week Sprint cylce to a 1-week Sprint cycle at Sprint or Project boundaries (i.e., before the Sprint in question starts). And even if it is not Scrum, I'm more concerned with it being Agile (as we already have an Agile-Scrum hybrid than it being Scrum).
Scrum says so. --> It is a way to distinguish 2 successful methodologies, but not critical for success, since both are succeeding. Still fits with Resources, Scope, and Schedule thinking.
Scrum relies on predictable inspect and adapt. --> Can one inspect and adapt with variable Sprint lengths? Yes, as long as people are flexible on the days meetings are held. (Thursday one Sprint and Friday the next. Even strict Scrum practitioners have to be flexible about moving meetings when there are Holidays.)
Scrum relies on predictable inspect and adapt. --> It is ironic that inspect and adapt was taken from Lean ideas and Lean Kanban allows variable length Sprints.
It would be difficult to measure your team's velocity with variable sprint lengths. --> That's what computers and algorithms are for to making charting easier. (In our program you just change the start and end dates of the Sprint and it works fine.)
*Might* affect the Team rhythm. --> Besides the fact that this was an acknowledged guess (as are my responses). There is a rhythm or synergy from getting features out their that the Customers give positive and more frequent feedback about.
PO may cram in too much to the Sprint. --> We planned exactly which 2 or 3 Stories would be done in our 1 week Sprints, so this is not a bigger problem than our current “urgent” interruptions. We are taking the same amount of stories and just delivering some of them sooner, so feedback and customer satisfaction should theoretically both go up compared to making them wait.

I totally agree with Ztere0. Dynamic Sprints are like walking the El Camino de Santiago...you don't walk the same number of kilometers every day...each journey is a different length. You determine where you want to be and sum the points to find how long it will take. I always stay within 30 days but I've found that if you always fix the sprint length you end up either wasting time because you finish early or you move items because you can't finish. I recently read Scrum Shortcuts by Ilan Goldstein and he too says the length should be fixed...I just don't get it...WHY FIXED??? The velocity can still be measured by summing all sprints and deriving and average velocity. I've been working as a director, manager, scrum master, product owner, developer, and analyst for 30 years and used Agile before Agile or Scrum was invented. I emphatically disagree that a sprint should ALWAYS be the same length. Still here, still successful.

I always get a kick out of those that comment "it's not Scrum" and quote a book...the whole idea of scrum is it's a framework, not a method. Frameworks permit flexibility to apply different steps based on the environment. If the organization wants to see something exactly every 14 days, then do fixed length sprints. Many, if not all of my clients have wanted to see specific completed modules and ask when can you give it to me? It's a matter of managing sprint scope...2-4 weeks.