Right length of the sprint
Hi
In our company, we are running SCRUM in weekly iterations. The management insist to keep such delivery period, but last sprint the Dev team started to explore a new area, one it had little experience with. At the end the goal of the sprint has not been met - we've been working with SME, but the plan the team worked out on a planning meeting turned out to be wrong approach and each day it was becoming clearer and clearer that the actual problem is too complex to handle it in the sprint. Nevertheless, we were able to figure out an algorithm that was part of solution. At the retrospective meeting the team asked about what we could do better, it answered: 'In this case, having in mind our level of knowledge, we would need a longer sprint'. Do you think it's the right way to proceed? On other hand PO could terminate the sprint when it became clear the goal will not be met, but I think it would do no good - the team would not gather experience it did, the algorithm mentioned above would not emerged and in fact team would continue to work on the same. Do you see any value/problems connected to altering the sprint length from sprint to sprint (taking into account the team assessment of the effort required)?
> The management insist to keep such delivery period
It isn't up to management to impose a delivery period. The Product Owner is accountable for what value is released, when it is released, and how often.
The Delivery Team and the PO should agree on a sprint length. It must satisfy the PO's interests in optimizing the release of value, and yet also be a timebox which the team can observe in practice. A degree of compromise may be necessary.
So, what does the Product Owner think the sprint length should be?
PO thinks the length should be as the 'business' dictates, in our case it's a week. We work for large company (the company is our client) and stakeholders/clients have lot of plans, ideas, stuff to do and they work in weekly cycles (status meetings, decisions, etc..), therefore they expect results on weekly basis. To be fair, I need to add, that so far, in case of this project weekly iterations worked quite good - mostly because of the type of problems to be resolved: quite good requirements and the team having lot of experience with dealing with them. The sprint I started the thread with was different from the beginning: problem was completely new to the team, the team had lot of stuff to learn and at the retrospective meeting, the team very openly said that in case of such problems a week is not enough.
Getting back to the sprint length itself: is it always fixed, not matter what? even if the team does not see (at the planning meeting) a way to deliver something valuable in given timebox? what if the lesson learned (after the sprint end) is: 'we need more time to accomplish something like that' but the business 'thinks' the other way?
> Getting back to the sprint length itself: is it always fixed,
> not matter what? even if the team does not see (at the planning
> meeting) a way to deliver something valuable in given timebox?
> what if the lesson learned (after the sprint end) is: 'we need
> more time to accomplish something like that' but the business
> 'thinks' the other way?
A Scrum Team is able to inspect and adapt its delivery process, including the length of Sprints. However it will also value a reliable and regular cadence for that process of inspection, adaptation, and delivery.
This means that a Scrum Team can indeed revise its sprint cadence, but only if there is satisfactory evidence that the proposed sprint length will be advantageous and sustainable in the long term. It *certainly* isn't something that a team would change on a tactical basis to try and fit the projected work for completion.
In your case there appears to be strong evidence that a sprint length of 1 week is appropriate and sustainable. Therefore, this isn't something that a responsible team would want to change, as there is no pattern of inadequacy which would actually support its revision.
It would be much better to help the Product Owner identify work which *is* achievable within the cadence that has already been demonstrated and proven. Use this sprint cycle to exercise control over any leap-of-faith that is needed before deliveries can be made. This might include testing some of the assumptions behind the algorithm you identified and its fitness for business purposes. Remember that Business is often unaware of such opportunities and may sometimes need help to see them.
Can you explain what do you mean by: 'Use this sprint cycle to exercise control over any leap-of-faith that is needed before delivery can be made'?
What stands behind sprints having constant length? What are the pros, especially in case when you up front know that the plan figured out during the planning session will not fit into the sprint?
> Can you explain what do you mean by: 'Use this sprint cycle to exercise
> control over any leap-of-faith that is needed before delivery can be made'?
If it takes X weeks to make a delivery, then the Product Owner will have to wait at least X weeks before he or she sees value being evidenced. It will take at least X weeks before the assumptions made in development are validated. Yet regardless of the value eventually evidenced, an investment will certainly have been made in funding the development effort over that period of time. There may also be an opportunity cost associated with other lines of experiment that were not followed instead. In effect, the Product Owner is gambling that the investment made will prove to be worthwhile. That's a leap-of-faith which is at least X weeks long. Clearly, the shorter the leap-of-faith that anyone has to make, the less risk will be incurred.
> What stands behind sprints having constant length? What are the pros,
> especially in case when you up front know that the plan figured out
> during the planning session will not fit into the sprint?
Rather than me answering that, what advantages do you think may be lost if Sprints aren't of a consistent length?
> If it takes X weeks to make a delivery, then the Product Owner....
I think it's not a case he - we came up to the solution where PO is available to the team during the sprint, cooperates with team members on daily basis, adjusts requirements based on needs, provides the feedback and actively takes part in acceptance testing (also during the sprint). btw is something wrong with this approach?
>Rather than me answering that, what advantages do you think may be lost if Sprints aren't of a consistent length?
To be honest, I can only think about 2 things: fitting to business needs (business may 'work' on regular basis) and the team's rhythm. Let's take first one: business needs something (by the deadline), but in fact the outcome of the sprint is always an unknown; it's an experiment so business gets no certainty only some prediction - in fact no 1 is nothing solid and valuable.
The second one: rhythm is important, but I don't believe the team will work efficiently when it feels uncomfortable about the feasibility of the entire attempt.
On other hand when we know the team's opinion and we follow its plan (with the sprint length extended) we maximize probability of delivering something valuable (the outcome is unknown, but at least we did everything possible to make it success). this way we also create conditions the team feels comfortable in and we limit cases when the team members overwork themselves to deliver what they've promised.
> ...is something wrong with this approach?
In Scrum terms yes there is. The Scrum Team...including the Product Owner...is failing to eliminate a significant variable which impacts their ability to inspect and adapt. By not making timeboxes constant, it becomes harder to compare experiences from one Sprint to the next. Each time there is a Review, Retrospective, or Planning session, some sort of allowance for this variability will be needed.
That can be a real loss when many other variables are also at play. A regular cadence can be the optimal point of refererence for inspection and adaptation in complex environments where those leaps-of-faith need to be managed and with minimal clouding of judgment.
Then again, if you're not facing that sort of complexity or uncertainty, perhaps you don't need Scrum.
> In Scrum terms yes there is. The Scrum Team...including the Product Owner...is failing to eliminate a significant variable which impacts their ability to inspect and adapt
The inspection takes place on-a-fly because PO collaborates with the team (but not controls it) and adaptation (on retrospective meetings) is also possible - the discussion is about how the cooperation with PO looked like, if there was something misunderstood, what worked out well and what didn't, etc... This kind of approach appears to me very in line with 'cooperation with customer' postulate and because of close cooperation brings lot of value (PO reacts very quickly while something is unclear to the team) and is also in line with one of whitepapers (I think it was one I found at Scrum.org, but I'm not sure) treating about continuous delivery which contained a very important statement about releasing the constraint of getting the feedback at the review session only (can't find the doc now, but I'll look for it).
>Then again, if you're not facing that sort of complexity or uncertainty, perhaps you don't need Scrum.
How would you characterized a 'complex' problem?
> ...about continuous delivery which contained a very
> important statement about releasing the constraint
> of getting the feedback at the review session only
That's correct. However, the situation you describe is contrary to the principles of CD, in so far as there is a desire to increase the length of a sprint and the time before delivery can occur.
> How would you characterized a 'complex' problem?
A complex problem - one which would justify the use of Scrum - presents risks that cannot be mitigated by daily inspection and adaptation alone. A longer term cycle of inspection and adaptation is needed (the Sprint) which allows greater uncertainties (framed as Sprint Goals) to be addressed. The variables are such that a regular cadence is needed to maintain control.
If something is too complex to deliver in one week sprint, there is also huge chance not delivering in two weeks because of mentioned complexity. Bigger item, bigger challenge to think it through. The ultimate goal is to be able deliver value as son as it possible. Increasing sprint length sounds like opposite approach.
Try to look on how to slice it. In the end value lies in learning curve. If team did smallest thing to check/reject approach used during sprint, it is better to know it sooner than later.
It is very ambitious for a Scrum Team to execute 1-week sprints. Congratulations if your team has been doing it for a while and succeeding in delivering business value.
I would concur that you should never adjust the sprint length to accommodate the story sizes accepted into the sprint. If your team has a Definition of Ready, it should contain a criterion stating that stories should be small enough to be completed within a sprint. For your team, that means story scope should be less than 1 week for the team to be able to finish.
If a story appears bigger than a 1-week sprint to the team, then it needs to either be reworked or split so that it meets the DoR and can be accepted. Under no circumstances should the team accept any story that they have reservations about being able to finish in the sprint.
Creating stories to represent experiments is perfectly ok. In fact, I'll quote Gojko Adzic - "Approaching stories as small experiments allows business stakeholders to learn through delivery and make better plans, instead of planning for everything upfront."
Agile principle #10 - "Simplicity, the art of maximizing the work NOT done, is essential." Business value is not always the work product that meets their specifications. It can also be identifying the right path/design/architecture/approach that eliminates working on wrong solutions.