Handling risks in Agile

One of my recent BAU Scrum teams ran a fortnightly risk review meeting. The risks were prioritised according to probability and impact and tracked in a risk register spreadsheet in Excel.

If there were Stories that the Team could work on to mitigate risks, these were added to JIRA. The Stories in JIRA and the risks in the risk register were linked.

The importance of the risks became part of the business value that the Product Owner considered when he prioritised Stories for each sprint.

When the stories were DONE in a given iteration, both JIRA and the risk register was updated.

Planning new Stories part way through an Iteration

Sometimes an iteration will get off to a brilliant start and it will become obvious that the Team will finish the planned Stories well before the iteration is finished. When this happens it is important to make sure that any new Stories that are planned in are planned properly.

When planning in new Stories consider the following:

Do

  • Make sure that the Team agree that ALL of the original planned Stories will get DONE.
  • Book an interim-planning meeting with ALL of the Team and the Product Owner to plan in the new Story(s).
  • Make sure that any new Stories are fully written and go through the same planning rigour as any Story planned in at the beginning of an Iteration.
  • Even if a Story is written and estimated it is important to review the Story as you would at any planning session to make sure the details, conditions of satisfaction and estimate are still accurate.
  • The Team must COMMIT to getting the Stories new DONE just like in any other planning session.
  • The new Story(s) become part of the Teams commitment for the Iteration and are included in any post Iteration metrics. If a new Story doesn’t get DONE don’t be tempted to wipe it from the records as it “wasn’t part of the original plan anyway”.
  • Review why the original plan wasn’t accurate at the Team Retrospective.

Don’t

  • Don’t pull work that the team cannot get DONE according to their Definition of DONE
  • Don’t just pull the next highest priority Stories off the backlog
  • Don’t plan in the new work at Standup
  • Don’t let the Product Owner make the decision for the Team
  • Don’t use previously written Stories without the Team fully reviewing them and confirming estimates

Why having extra capacity part way through an Iteration isn’t always great.

It might seem like a good thing to have a load of extra capacity part way through an Iteration but underplanning an iteration is still a failure to estimate and plan accurately. Also planning in new Stories part way through an iteration is less efficient than planning the same Stories the beginning so there is an impact on Velocity.

Retrospective

At the Retrospective ask why they original plan was underestimated. Understanding why we weren’t accurate will help is plan the correct amount of stories in future iterations.

A lesson in how to handle customer feedback on a website.

Last night I was using http://www.homely.com.au/ and a couple of the filters wouldn’t work. I noticed they had a ‘Help us with feedback’ button. so I clicked it and said what was happening. Experience has taught me not to expect too much with these things so imagine my surprise to receive this email less than an hour later

Hi Carl,

Thanks for the feedback, much appreciated. We have tested the link, and it looks like you had ‘Rural’ selected when browsing on a non rural area.

I ran a test on Chrome 35 and Windows 8.1 and our filters seem to be working.

Here is the same link, without any filters activated: http://www.homely.com.au/buy/bondi-junction-waverley-sydney-greater-new-south-wales

Can you confirm if you are still having troubles with the price filters?

Kind regards,
Laura
Homely Customer Team

Lessons

  • Have a prominent button on your site that asks users to help you with feedback
  • When users give feedback capture other useful information like URL, browser, OS …
  • Respond immediately with a useful answer

Users will be blown away as this experience should be far better than what they are used to.

homely

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?

Pizza

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

Usage

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

http://www.weeworld.com/
Limited options without starting an account but quick and easy. Requires a screen grab and crop to save avatar

http://pickaface.net/
Head shots only but very versatile

http://www.dudefactory.com/
Lots of options and lots of fun

http://www.sp-studio.de/
Great for south park fans

Or Google for many more options.