Forums

By posting to our forums you are agreeing to the Forum terms of use.
Dynamic length of sprints in Scrum
Last Post 14 Feb 2014 07:54 PM by Richard Lynn Paul. 16 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages Not Resolved
Ztere0
New Member
New Member
Posts:3
Ztere0

--
30 Apr 2013 09:31 AM
    I have been working several projects with Scrum method and, in some, we have taken the decision of execute Scrum sprints of dynamic length (base the Sprint length in the work inside every Sprint, and not fixed length).

    For me it have some advantages:

    Adapt the Sprint length to the "real" work charge by Sprint (always respecting the Sprint min-max duration rules).
    More simple planification of Sprint (not have to "play with" the end of the Sprint to fix the lenght)
    Easy to adapt complete functionalities in short planifications.
    The main dis-advantage is that feedback to the client is sent in variable time spaces, but if they are informed and confortable with this, there are no problem.

    Is this an accepted practice in the Scrum method?
    Christiaan Verwijs
    New Member
    New Member
    Posts:5
    Christiaan Verwijs

    --
    30 Apr 2013 11:51 AM
    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?
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:559
    Ian Mitchell

    --
    30 Apr 2013 01:30 PM
    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.
    Rob Wesley
    New Member
    New Member
    Posts:4
    Rob Wesley

    --
    30 Apr 2013 08:03 PM
    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.
    Ztere0
    New Member
    New Member
    Posts:3
    Ztere0

    --
    01 May 2013 03:29 AM
    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.
    Rob Wesley
    New Member
    New Member
    Posts:4
    Rob Wesley

    --
    01 May 2013 05:54 AM
    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.
    Sanjay Saini
    New Member
    New Member
    Posts:78
    Sanjay Saini

    --
    02 May 2013 02:13 AM
    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.
    Chee-Hong Hsia
    New Member
    New Member
    Posts:61
    Chee-Hong Hsia

    --
    10 May 2013 09:39 AM
    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
    alicemenezes
    New Member
    New Member
    Posts:39
    alicemenezes

    --
    15 May 2013 06:50 AM
    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/
    Joshua Partogi
    New Member
    New Member
    Posts:98
    Joshua Partogi

    --
    15 May 2013 09:57 PM
    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!
    Ztere0
    New Member
    New Member
    Posts:3
    Ztere0

    --
    16 May 2013 01:18 AM
    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,
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    16 May 2013 11:21 AM
    Sounds more like waterfall than Scrum. It's definitely not Scrum.
    Simon Reindl
    New Member
    New Member
    Posts:28
    Simon Reindl

    --
    16 May 2013 02:16 PM
    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.
    P.Ross
    New Member
    New Member
    Posts:84
    P.Ross

    --
    17 May 2013 12:34 PM
    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?
    Simon Reindl
    New Member
    New Member
    Posts:28
    Simon Reindl

    --
    20 May 2013 05:28 AM
    @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.
    Vasan
    New Member
    New Member
    Posts:6
    Vasan

    --
    01 Jun 2013 01:27 PM
    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.
    Richard Lynn Paul
    New Member
    New Member
    Posts:3
    Richard Lynn Paul

    --
    14 Feb 2014 07:54 PM
    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.
    You are not authorized to post a reply.


    Feedback