The case for re-estimating Stories that do not get DONE

We want to build to a DONE culture where teams strive to get every Story DONE, every Sprint.

Taking a relaxed attitude to finishing Stories in the following Sprint doesn’t help set the expectation that DONE is something to strive for.

Partly DONE Stories can lead to an test heavy plan in future Sprints as developers code right up until the end of the Sprint instead of swarming on the Stories the team have already committed to and getting them DONE.

Not DONE Stories are wasteful.

Like it or not, Team’s often equate SP to credit. They often ask, “how do I get my points (credit)”? By letting Team’s take their credit/SP in the following Sprint it sends the wrong message about working towards DONE. Only giving SP/credit for DONE Stories incentivises teams to think about getting Stories DONE if they want the SP/credit.

Team’s velocities are calculated by summing all of the DONE SP and dividing by the number of Sprints. This leads to a slight overestimation of what the team can actually get DONE as it includes SP that got done and SP that the team could not get done. Overestimation leads to over-planning and this has costs associated with it:

Striving to complete the Sprint backlog that the team committed to in Sprint Planning encourages the team to master core Scrum practices that will help the Team get their Stories DONE eg

  • Story writing
  • Estimation
  • Splitting
  • Planning
  • Collaboration
  • Swarming
  • Cross functional behaviours eg developers testing
  • Actively talking about how to get all of the Stories to DONE
  • Scrum ceremonies

Teams need to do some sort of re-estimation of any partially completed Stories so they know how many SP are left for new Stories in the coming Sprint. If some sort of re-estimation of remaining work isn’t completed then there is a risk that the team will be over-planned.

Quick and informal re-estimation of Stories that didn’t get DONE eg by the dev who is working on a Story, are likely to be less accurate than a formal re-estimation process eg whole team and planning poker.

If you are re-estimating anyway, why not update the Stories in the next Sprint with the more accurate numbers?

If a team re-estimates SP but doesn’t update the Stories then only insiders in the team with the secret estimates can accurately read boards, Sprint Burnup/Burndown.

If Stories aren’t updated it makes it difficult for outsiders (RTE, PM, Sponsors etc) to assess how the Sprint is progressing by looking at boards and in tools like JIRA eg if an 8SP Story
hasn’t been started with 3 days to go on a Sprint, is that a problem or not?

If Stories aren’t updated with the new estimates then it can be difficult to interpret reports like burndown charts eg how did the team get a 5SP Story done on day one of the sprint? If the 5SP being burnt on the first day obviously isn’t an accurate representation of effort expended then how can we trust any of the other changes in the Spring Burndown Chart.

Sprint plans with accurate, re-estimated Stories are more honest and transparent. Because of this, better decisions can be made.

Stories that don’t get DONE within the Sprint are wasteful

Every Story that is partially DONE within the Sprint still has to go through some of the following Steps to get DONE in some future Sprint.

  1. The PO must prioritise the Story again
  2. The Team must review and rewrite the story removing the parts that are not required and adding any missing detail and conditions of satisfaction
  3. If the Story is much larger than originally estimate then it may need to be split
  4. The Story must be re-estimated so the team can make a good Sprint Plan
  5. The Story has to be tasked out on the Team Board
  6. The Story must be coded
  7. The Story must be code reviewed
  8. The Story must be retested from scratch across all test cases on all systems, devices and browsers etc
  9. Bugs have to be raised and fixed
  10. The Story must be signed off
  11. Throughout the Iteration the Team must update JIRA/Rally, talk about the story at Standup and communicate with each other in a timely and effective manner to ensure it passes through the Team’s Iteration workflow.

In short, any story that does not get DONE, even stories that are “99% DONE” will still require a fair amount of work from several people in the Team in the next iteration. Teams should be aware of this and they should focus on getting the maximum number of Story Points DONE.

Scrum – Sprint Planning Checklist

A simple checklist for planning a Sprint Backlog.

  1. Quick refresh of change suggestions from previous Retro
  2. Set a Sprint Goal
    1. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment – The Scrum Guide
    2. Goals should be SMART eg Specific, Measurable, Achievable, Realistic and Time-bound.
  3. Capacity Plan – Log team availability in the coming sprint (including feature owners)
  4. Agree Velocity – Based on previous Sprints’ velocity, adjusted for capacity changes
  5. Re-write and re-estimate any not DONE Stories from the previous Sprint (if they are still a PO priority)
  6. Finish writing any incomplete Stories from Grooming
    1. Split Stories where possible – smaller is better
    2. Write Stories according to INVEST http://codesqueeze.com/how-to-invest-in-your-user-stories/
    3. Write tasks on postits
    4. Estimate using planning poker – use fingers for 1, 2, 3, 5, 8, 13, 20 …
  7. Pull prioritised and Estimated Stories into Sprint Backlog  until the Velocity is reached
  8. Hold a fist of 5 vote to check Team’s confidence in getting every Story in the Sprint Plan DONE http://agileanswerman.com/5-reasons-a-scrum-master-should-use-fist-of-five-voting/
  9. Team Commit to getting all of the Stories DONE
  10. Team put printed Stories from Rally and Tasks on their Board
  11. Team hold a mini-huddle to agree the tasks that each Team member will start on first (probably after lunch). Move tasks into In Progress with Avatars.
  12. Update the started Stories in Rally!

New Blocker Template

This is my new Blocker template for use on Scrum Boards and other visual management boards (VMBs).

 

I use blockers when I want to clearly visualise that something is blocking a story or stopping a team from meeting it’s planned goals.

The characteristic of a good blocker are:

Big

Big blockers can’t be missed and they give plenty of space to write the cause of the owner of the blocker on the card. I’ve attached a template below but I usually print about six per A4 page.

RED

Red is a warning colour and we avoid using it unless we want to call attention to a problem.

Informative

Have a space on the blocker to write brief details about who or what is causing the blockage. Some team only put a red X on the impacted work, I call these mystery blockers, because there is no information about what the blockage is.

Date

Blockers should also be dated as soon as they are placed on the board. This way everyone will know exactly how long the blocker has been an issue. If blockers are an ongoing issue for a team the dates can be recorded and tracked as a metric like average blocker cycle time (how long from a blocker going on a boar to being cleared). Different blocker strategies can  be trialed and you can see if they have a positive or negative impact on average blocker cycle time.

Owner

Blockers should also have a clearly identified owner who takes responsibility for clearing the blocker and get the work progressing again.

Placement

The blocker should be placed right next to, but not on top of the task, story, feature etc that is blocked.

Printable Blocker Template

Blockers with text boxes and dates

Scrum – Should a Product Owner vote in Planning Poker?

Product Owners definitely do not vote or otherwise influence the Team’s estimates during Planning Poker (unless they are also developer).

Basically, the best people to give estimates are the ones who will actually being doing the work.

The PO Fallacy

The PO Fallacy is that if the PO convince the team to give lower estimates then they can get more work done. They mean well as they are probably thinking about strategic goals, what their leaders wants or customer satisfaction. But the likely net result of compressing Story Point estimates is some or all of the following:

  • Overloaded Sprints
  • Not getting all of the Stories DONE that the Team committed to
  • Stories that do not meet the Team’s Definition of Done
  • Quality drops as Stories are rushed
  • Tech debt caused by the Team taking shortcuts to get everything completed
  • Unsustainable pace as the Team work evenings and weekends to complete the work they committed to
  • Unhappy developers
  • Staff turnover
  • Reduced velocity in the future as new team members are brought up to speed

How do PO influence estimates?

PO are often unaware of the effects of encouraging teams to compress their estimates. In this situation they might do the following:

  • Directly ask the Team to give a smaller number
  • Challenge the legitimacy of the estimation even though they lack the technical knowledge to do so
  • Challenge team members who give higher numbers during the initial rounds of estimation
  • Let the team know in advance what “has to be done”

Sometimes POs are aware that they shouldn’t be challenging the Team’s estimates so they use less direct methods.

  • Let a confederate in the team like a Scrum Master or a senior technical person know exactly what “has so be done” in the Sprint prior to the estimation session. The confederate then compresses the Team’s estimates on behalf of the PO
  • Give subconscious cues like laughing, making faces, rolling eyes when the team or a team member gives an estimate that they think is too high

What should the PO do during estimation?

Generally the safest approach is for the PO to stay silent and still and trust the team to come up with an accurate estimate.

More information https://www.infoq.com/news/2010/08/product-owner-planning-poker

Making Great Avatars and Team Sheets

I make photo avatars for everyone I work with. Photos are great for putting on team boards showing who is working a given task or story.

What is the difference between a good avatar and a bad avatar?

Good avatar Bad avatar
harambe ca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-smallca-small
 Clearly identifiable passport style photo (no sunglasses, facing the camera, take in the last decade etc)  Not really sure who this is? Maybe the American guy in the team?
Clear name No name
Great for learning new names No idea who anyone is
Helpful for visitors to address team members by name “Um, who is this again?”
Great for showing ownership and pride Still not sure who it working on this
Big. Avatars should be big enough to be read by anyone within three meters of the Team’s Board. Someone always asks me if their avatar could be smaller. My answer is that they could, but that they wouldn’t be fit for purpose Too small
Usually only three per team member to encourage them to limit Work In Progress (WIP) Why are there so many of these? Who is doing all this work? Why is nothing getting DONE?
There’s only one Harambe Everyone wants to be Captain America (or Hulk)

Team Sheet

Once I have avatars for the whole teams I pull them all together and make them into a document that I call the Team Sheet.

  • One goes on the top of the Team’s Board.
  • One goes on the program board for Scrum of Scrums
  • The team take one with them to planning events, hackathons, anywhere they are representing as a Team
  • One goes on the front page of the deck they make for Showcase
  • Three more get printed for lamination and cutting up into avatars.

Link to avatar template in Word

team-clear-avatars

ownership

Starting your backlog again – nuclear backlog grooming!

One Scrum team I took over had a backlog of over THREE THOUSAND STORIES that the business “needed to get done”. Given that the team has a velocity of about 30 stories in each iteration and their iterations were two weeks long this meant that if no new work arrived they theoretically had enough work to last them for almost four years, assuming no new stories were added.

To clean this mess up we started a brand new backlog and stopped using the old backlog.

We then worked with the current business stakeholders and the team to identify what they really needed and added those Stories to the new backlog. This worked for everyone. The business were able to identify and prioritise what they really needed. Everyone got a much better idea of the highest priority work and what was coming up in the near future. The nagging doubt that there were high priority Stories lingering somewhere in the monster backlog was removed. The team also felt less pressured and more involved in their work coming up. Planning also became much easier.

In the year I worked with this team we only ever pulled one story form the old backlog into the new backlog.