Scrum – Why we try to avoid changing the plan part way through an iteration

In an ideal world, once a team has started an iteration then the iteration plan should not change.

Changing Iteration Plans

Here are some of the reasons why you shouldn’t change an iteration plan:

  • Changes cause churn and additional administration that will negatively impact velocity. Stories that have been started and dropped will have to be rewritten and re-estimated in the next planning session. New stories will probably have to be written and estimated in the middle of the iteration.
  • The teams remaining velocity can be difficult to calculate part way through an iteration thus the replanning is likely to mean the iteration is under-planned or over-planned. An under-planned iteration will mean that a third round of planning will have to take place. An over-planned iteration means some stories will not get DONE and they will have to be rewritten and re-estimated in the next iteration …
  • The most common Scrum iteration duration of two weeks is a small enough window of time for the business not to have change its mind. Twenty-six opportunities to change your mind in a year should be enough even for the most indecisive product owners.
  • Refusing to let the product owner change the iteration plan sends them a clear message that they have to plan better in future because they won’t be allowed to make changes mid-iteration.
  • Replanning suggests that there has been a critical failure of planning and prioritisation by the product owner during the planning of the iteration. This should be talked about in the retrospective.
  • It’s not good for team moral to change the plan/stories that they worked hard to create and have committed to.
  • It will distort any Scrum metrics that you are capturing eg story points done, which are useful for calculating velocity.
  • It’s part of the scrum masters job is to protect the team from forces outside the team eg indecisive business people.

That said there will always be exceptions any good rule. But these changes should be the exception.

Virtual Development and Testing

Today I did 10 hours of “virtual development and testing” and it cost the company $320.

We have a release coming up. The scrum teams have been working hard to get a responsive site ready to go.

Because we’re Agile we are working on the most important issues first. So we know were going to get the most important stuff done. But it would be great if we had a little move capacity so we could get through a little more of our backlog prior to release (isn’t it always?).

As an Agile Coach I can’t develop or test at the same level as the team members.

So how do I help?


For Friday lunch we ordered $320 worth of pizza.

The developers and testers were stoked that they all got free pizza for lunch.

The average time to eat the pizza and got back to work was well under 20 minutes.

If we assume that the average team member takes 60 minutes for lunch (conservative for a Friday) this means we gained an extra 40 minutes of dev/test capacity per team members. This equates to 600 minutes or 10 hours of extra capacity.

By buying $320 worth of pizza the company earned at least 10 hours of extra development/testing time. A bargain if ever there was one.

Agile avatars, usage and resources

Avatars are picture representations of the members of the scrum team that are used on Scrum and Kanban boards to show what each team member is working on.



Avatars are moved by the individual team members they represent at the daily stand-up. Prior to stand-up avatars will be placed next to the stories/tasks that the team member has been working on the in the previous day. During stand-up when the team member says what they will be working on in the upcoming day they should place their avatar(s) next to the relevant story/task on the board.

Everyone should have two or three Avatars for times when they are working on more than one task over the next day. As a general rule avatars should be limited to two or three because generally it’s good for productivity and throughput to limit work in progress (WIP).

Avatars should always include the name of the team member so that people from outside the team can identify who they are.

Colour coding can be used to indicate the primary functional skill of the team member eg tester

If your Scrum board uses regular sized postits, make sure your avatars are no taller than the size of postit notes so they can be clearly aligned to tasks without obstructing the tasks above or below. This is especially useful on busy agile boards with a lot of stories on them.

Online avatar resources

There are loads of great free online sources for Avatars
Limited options without starting an account but quick and easy. Requires a screen grab and crop to save avatar
Head shots only but very versatile
Lots of options and lots of fun
Great for south park fans

Or Google for many more options.

Book Review – Agile Product Management with Scrum: Creating Products that Customers Love


The book was small and easy to read and a good guide to any product owner who is just starting out working with Agile teams. I’ve recommended it to my company’s fledgling PO team.

The book covered the basics of PO work and then how to successfully integrate with an agile/scrum team.

Not sure it delivered on creating products that customers love part.

But what it didn’t cover, that I thought it might from the title, was how an enterprise might use agile to successfully manage multiple products in an agile way and therefore deliver maximum business value.

Book available from Amazon

What makes a good Scrum board?

The litmus test of a good Scrum Board is its ability to quickly and accurately communicate the state of the Iteration to people inside and outside of the team. The challenge is that the board must contain enough technical information to guide the team but also enough high level information that people outside the team can understand what is going on.

There is no such thing as the perfect Scrum Board. Every team will require a different implementation of the Scrum process that works best for them. That said there are some common factors that should be considered for all Scrum Boards.

General information about the team that people outside the team may want to know:

  • Team name – tells you what team is called and useful in an environment where there are several teams and boards
  • Vision – concisely tells you what the shared goal of the team is
  • Definition of Done – tells you what the team need to do to complete each Story
  • A list of iteration start dates – Lets you work out how far through the current Iteration the team are and by having a list it saves rewriting this information each Iteration

Current Iteration information

  • Clearly labelled columns
  • Clearly written Stories and Tasks with Story numbers on each ticket
  • Stories ordered by priority with the highest priority stories at the top of the Board
  • Use colour to differentiate types of stories or tasks, some examples of how to use coloured postits include
  • Type of task – testing, development
  • Different projects
  • Different Epics or Features
  • BAU v project work
  • Urgency
  • If different coloured postits are used then there should be a Key showing what the different colours mean
  • Avatars should be used to show who is working on what
  • Avatars should have names on them so it is clear to outsiders who they represent
  • Markers should be used for blocked stories (also on the Key)
  • A mechanism for capturing significant non planned work eg on an unused colour of postit. These can be reviewed every few retrospectives to see what common issues you are missing that could be planned for
  • Burndown chart to show how the current iteration is progressing
  • Release tracking if releasing is not included in the Definition of Done
  • Board discipline

    • Stories and tasks should be neatly written so they can be read from a reasonable distance
    • Stories and tasks should be neatly laid out with no overlaps
    • Stories and tasks should be should be positioned so any associations can be clearly understood

    Most boards will evolve over time to meet the needs of the team. It is useful to photograph the Board at the end of each Iteration so you can go back and see how your board evolved.

    Riding from London to Paris with (almost) no training

    A friends cycled from London to Paris recently with little training. As someone who has did this once on a hybrid it got me thinking what could you do to make the ride easier if you haven?t put the hard training kilometres in up front.

    This is what I came up with:

    It is (almost) never too late to train even if you only have a few days to go some sensible longish rides will do you good.

    Consider getting a road bike if you have time to do a few rides and get used to it before you leave.

    Get your bike serviced before you go. It?ll be less likely to break and will have less grit and new oil etc. A recently serviced bike is and efficient bike. Take the serviced bike for at least one good distance ride before you leave do find out if the service has caused any issues.

    Pump your tires up properly every day. Hard tires are more efficient than soft tires.

    On the ride never be tempted to race or go fast. Always start each day slowly for an hour.

    Find other people who want to ride at your pace and ride in a close group with turns at the front. It?s a lot harder to be the first person in a group hitting the wind so taking turns shares the load. Getting behind a large person is ideal ?

    Make sure you have good quality carbs for breakfast, lunch and dinner. Porridge and pasta are ideal. Snacks are a good idea too. You (probably) can?t overeat on the ride. Drink lots of water and isotonic (with salt) drinks to keep your fluids up.

    If anyone is offering a leg massage definitely accept

    Get as much sleep as you can each night

    Don?t drink alcohol until you finish the final day.

    Riding from London (Russell?s) to Brussels

    Cam, Russ, Grant, Steve, Phil and I rode from London to Brussels for fun. Since we started at Russell?s flat in Balham we coined the ride ?From Russell?s to Brussels?.

    Kelvin and Louise kindly offered to drive a support van for us. Nothing happened between them and Steve has nothing to worry about.

    The Route

    London to Harwich (overnight ferry to Hook of Holland)
    Hook of Holland to Amsterdam
    Amsterdam to Breda
    Breda to Brussels

    The total distance was about 550kms but I?ll never really know as my Garmin 910xt stopped recording new route information after Breda. Note for next time, record each day as a separate ride.

    Day 1 ? London to Harwich

    Started the day with Steve getting a flat, followed by Phil. Steve likes to get the first flat on these long rides.

    Great warm sunny flat ride all day to Harwich. Harwich has a Morrisons right next to the Port which was excellent for refuelling hungry cyclist prior to the ferry.

    The overnight ferry was affordable, good quality, comfortable beds, brilliant showers and a it had a bar ?. Just what everyone needed after a long day in the saddle.

    Day 2 ? Hook of Holland to Amsterdam

    Day 2 did not go well. Despite the ride being in June/summer the weather was shockingly wet and cold. Hardly anyone had the right cold weather gear to keep warm in the conditions. Luckily I had enough of my commuter cycling clothing so wasn?t too bad. Also the non-commuters had no experience of riding in snow and sleet so it was a bit of a shock for them. At midday we found a mall to hide in and drink lots of hot drinks for a couple of hours. Even luckier the mall had a cycle shop and the boys blew around three hundred euros on cold weather gear.

    Day 3 – Amsterdam to Breda

    Weather greatly improved but still not really summery. Spent the day getting lost. Amazed by the cycling facilities in Holland.

    Day 4 – Breda to Brussels

    Final day into Brussels followed by a massive team meal and session on the rums.

    All in all a fantastic ride with good mates and lots of good memories.