Skip to content

Scrum Puzzle #2

Wow, I’m overwhelmed by the great response to the first Scrum Puzzle. I loved some of your responses. I especially liked Matthew’s example of moving the boulders. That’s a great way to teach the principle.

Here is my solution:

There are 2 key learning points in this puzzle. Number one is the value of small batch sizes. There are numerous exercises to demonstrate this. Check out the penny game as an example. Most of you got that the stories really need to be broken down smaller. This is often difficult for new teams, but there are techniques you can use to do this. See my previous post on breaking down user stories. If we don’t have small batch sizes, then it takes longer to complete work, progress is less transparent, feedback cycles are longer. All of these are things we are trying to avoid in Scrum, so any solution which makes the batch size larger is generally not a good idea.

The second problem in this puzzle is the statement that only 2 developers can work on a large story at a time. While I accept that this might be true. This is an impediment as it slows down the speed at which the team can deliver the most important features. Instead of taking on additional stories, or being idle, they other developers in the team should be looking at how to refactor the code, or their development practices so that more people are able to work concurrently.

In summary, I believe the ScrumMaster should switch to mentoring mode, explain the value of small batch sizes, and question what prevents them from having more people work on the story. Ask the team how they might solve this problem differently, keeping that in mind. Hopefully the team will realise that a better solution is to split the story, and address the reasons why only 2 people can code at a time.

And now for this week’s Scrum puzzle….

Scrum Puzzle #2

Your team has an established velocity of 30 points per 2 week sprint. A client has an urgent regulatory requirement which was previously missed. The client is due to launch in 3 weeks time, but will be prevented from launching if the regulatory requirement is not included. In backlog grooming the team have sized the work as 45 points. The product owner is thrilled because if he runs a 3 week sprint he should get 30 x 1.5 = 45 points, so the team can deliver in time for the client’s deadline. You are the Scrum Master. Do you allow the Product Owner to change the sprint length this one time to assist the customer?

5 Comments Post a comment
  1. I would advise against it. The team may not be able to complete the work. I have seen that you cannot calculate velocity for 3 weeks by dividing time and velocity for 2 weeks and working out a teams 3 week velocity. By changing the sprint length you are hitting the reset button and the teams velocity is now unkown. The achieved velocity may in fact be less than 45. Dividing velocity and time to get a factor is mixing concepts, its tempting to try work out velocity and time this way but it doesn’t work. Rather ask the team what work they think they can deliver in a 3 week sprint and encourage an open honest coversation with the team and po.Its also important to mention to the po that breaking the teams rhythm may impact the next sprints velocity as teams experience problems adjusting to fluctuating sprint length and this can have a negative impact on for the next sprint as team members tend to get confused, not knowing when they should be doing what with regards to planning for the next sprint. The team could also feel rushed
    and quality could suffer in the 3 week sprint. At the end of the day I feel delivery is the key business driver and if knowing all the risks the po still wants to try a 3 week or 2 week and 1 week sprint, then it should be done. Make sure you discuss this in the retrospective and try to find out if there is a way of avoiding these variable sprint lengths, chances are you could get earlier notification on critical work and that way align the work with your sprints. The danger of allowing variable sprint lengths is you are making it easier to break the rules again, so you must find out why this happend and remove this problem so it doesn’t become the norm. Some po training may be required. Hopefully the po can be convinced that his/her calculations are inaccurate and agrees to ditch the idea of a 3 week sprint. Rather than saying no, explain the problems associated to fluctuating sprints and you may find the po is no longer willing to try this.

    September 30, 2011
  2. Hmmm… this is long… sorry this is trend with me 🙂

    Some initial observations:
    1. Are we deploying every sprint to live already? Or is this a big bang release? Big bang is usually more overhead as you’re not doing it as often and we hence haven’t necessarily optimised this. This might mean that there are other activities like regression testing or hardening (that I’m sure none of us need to do because we’re all doing it every sprint ;D) that need to be included into that 45 points / 3 weeks calculation. It becomes easier to say you missed the train and the next one is in 2 weeks rather than you missed the train and the next one is in 3 months. And it also means that the deployments are probably less painful if you’re doing them in short intervals.

    2. I have had a client look at the backlog and tell me you’re making X points per 10 day sprint, that is X/10 points per day so in the next 13.5 days you can make Y points – so please go and do that. I had to laugh a little – then cry a little. I have had teams move from 1 week to 2 week sprints and 2 week to 3 week sprints on their own volition. The velocity is not a direct linear process. It is fine to use that as a guess – but it is a guess – and relying on it for the first sprint is a bad idea. Just like changing the team composition isn’t predictable. I’d spend a bunch of time impressing this on the PO. Burndowns can be a quite useful tool to show this as most teams don’t have a perfect linear graph every single sprint which will illustrate this quite well.

    3. When did the deployment date get decided? Currently the PO is offering it up in 3 weeks time. This isn’t in the current sprint cadence hence it may be safe to assume the PO/someone else has decided unilaterally on the date without consultation based on the new functionality. In which case this becomes an education exercise of please ask us as there are no miracles here. And I would be a lot more pig headed about not just caving.

    4. Is the deadline based on any real business imperative? I have only experienced a real business imperative once and even then I was a bit frustrated with it. But if a company (your company?) is being fined $2 million a day for every day that you are non-compliant – something radical needs to done. Everyone needs to chip in and help solve the problem – be that pulling the system offline (and the associated costs) while it gets fixed in 4 weeks or making Scrum work for the scenario (1 week sprints?). But as I say – this is almost NEVER the case. So you need real understanding of what the _real_ implications are of doing anything radical.

    That said – let’s not be radical – and look at options:
    For all of this – explain the above to the PO. Explain the impact of changing the rhythm and why we’re not going to do it just because the numbers work.

    a) Assuming deploying every sprint: The train goes in 2 weeks time – please prioritise your backlog to get the highest priority work in this sprint. Next train goes 2 weeks after that. Make sure that everything that is business critical is in the right priority. And have a discussion.

    b) Assuming larger deployments – do the same but deploy a patch after the 2nd sprint if it is drop dead functionality.

    Both a & b assume we can do something about the priorities and that there is value in releasing early.

    c) Explain to the PO that the order of the items that come into the sprint are prioritised by the PO. The order we do things is their prerogative. How much we pull into the sprint is the team’s prerogative. So suggest the PO place a story on the backlog to deploy the software once all the 45 points is done. At that point – no matter where we are in the sprint – this is the highest business value item to complete and delivers value to the client. The team can commit to trying as hard as possible – and when everything is ready – they’ll release. If that turns out to be 3 weeks bonus – but no guarantees. If we’re ready, we deploy. Worst case this will be 4 weeks time – we expect. But if we’re ready any time before then – we’re not going to sit around and contemplate the stars while we do other lower priority work.

    This does open up another issue – what if the team doesn’t make it? If they fail their sprints or the functionality is more complex than anticipated and the work grows – what are the implications to the release dates. This needs to be understood within the context of all discussions around any of this as there are no guarantees.

    d) Another potential option is to ask the team – what do they believe we can do to help the PO. It isn’t the POs call to change the cadence of the sprint. It is the team’s. The PO can ask. And team can commit to giving it a try. But I’m now more inclined to recommend moving to 1 week sprints rather than one 3 week sprint if we do have a drop dead critical deadline that will be costly to avoid. This will shorten the feedback loop instead of increasing it. But fundamentally it is up to the team to talk it through and the pros and cons of the options should be provided.

    I generally aim for c if I can’t convince them to reduce the scope. And the end date doesn’t change from the 4 weeks – but we’ll try for earlier and hope it isn’t later.

    My 2c 🙂

    September 30, 2011
  3. This sounds like a real example:
    My initial thoughts:
    1. “That’s nice…”
    2. Is this “missed part of work” part of an existing delivery?
    3. Have the conversations with the PO explaining rule 1, “we are a scrum team” and this is why we do what we do.

    …now blood starts flowing…
    It’s awesome to know that there was a deadline before the team had a look at the work.
    So the PO makes the rules now? In my experience if you allow the PO/ Business whoever it may be, team members start to lose RESPECT for you.

    So my short answer is to explain to the PO why it cannot be allowed (nicely) and yes we’ll assist the business to get the work done but here are the team rules.

    Note to self:
    If the team decides to change sprint length I’ll advise to have shorter iterations (couple of days, a week no longer) – we will need the quick feedback especially if it’s business critical.

    October 2, 2011
    • Karen Greaves #

      Or as Mitch would say GFY – Good for you 🙂

      October 2, 2011
  4. I’m working on the presumption that we’re just about to start a new sprint when this urgent requirement comes in.

    My natural reaction is to consider the needs of the business first. They have a clear and pressing need for this extra functionality so my response would be a “Yes, but …”. But my first move would be to “Take it to the team”. The requirement needs to be thoroughly discussed and understood in the Sprint Planning Meetings. Then, if the Team believe it can be done, let’s do it.

    Whilst I agree that temporarily changing a Sprint duration will upset the natural order of things, it’s an exception to the norm and when treated as such won’t affect much. The Team exists to service the business, not be a slave to process. In this example, we are breaking the normal rules (ie: Sprint duration) but we have a clear reason for doing so. This type of flexibility is common and welcome in agile.

    February 29, 2012

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: