Seeking “Customer” Input

Reading time ~ 3 minutes
Overgrown statues
The hidden beauty of exploration

Those of you that have been following my posts in the past will have noticed my output has significantly reduced in the last few months. I still have plenty of articles to write but I’ve chosen to spend much more of my spare time outdoors exploring “old places” and enjoying rocks, trees and water and those things that are half-forgotten.


I still want to keep writing and feedback I’ve had is that it’s been worthwhile for you readers so far – so how do I get more focused?

You’ve (hopefully) seen the fairly broad spectrum of things I write about already. Rather than my continuing with random musings as they surface (or mature naturally from my backlog of posts) I’d like your input.

Taking a cue from an article I read a few months ago (I really wish I could remember the site and author) I thought I’d share the headings from my backlog publicly.

If any of the draft titles below spark your interest, please comment and let me know and I’ll prioritise them in my backlog and work on expanding them into full posts.

Similarly, if they inspire something else that you think I could share, just shout.

All the best from the shores of Porta Rossa


The Captain’s (Back)log

  • Analysis Vs Delivery
  • Why You Should Stick to Using Whiteboards & Stickies
  • Estimates Are Not Commitments
  • Sub-optimizing Around Data
  • User Story Myopia
  • On Average Everything Is Average
  • The Story Point And The Damage Done
  • The Cuckoo’s Egg
  • The Automobile Association (On Setting Customer Expectations)
  • What’s Wrong With Your Picture?
  • The Problem With Big Problems
  • Give Me Something To Critique
  • Using The Pirates Code With Agile
  • Trust or Blame
  • The Management “Middle Tier”
  • Managing The Sushi Bar
  • Using Real Options With Your Suppliers
  • Scale, Supply And Demand
  • It Really Does Depend on Context
  • Stop Trying To Fix Your Weaknesses
  • Dietary Manipulation (Part 6) – Eat Together
  • Dietary Manipulation (Part 5) – Have a Beer
  • Dietary Manipulation (Part 4) – “Do Food”
  • Scrum/Kanban Board Refactoring
  • The Pitfalls of Measuring “Agility”
  • Single Piece Flow and Trading Out Stories
  • My Job is to Make Myself Redundant
  • Escaping The Oubliette (Part 6) – The SWAT Team
  • Escaping The Oubliette (Part 5) – Sponsorship
  • Do No Harm
  • Commitment & Planning Horizons
  • Project Envisioning with Six Stickies
  • Don’t Wait For a Retrospective To Improve
  • Technical Debt – Eating My Own Dog Food
  • Technical Debt (basics)
  • Critical Chain Estimation
  • Thinking Too Big
  • Creativity
  • Pairing, Peer Review and ISO
  • 1,000% Improvement Is a Statistical Outlier
  • Stop The Line
  • Zero Defects
  • What Documents Do Your Projects Produce?
  • Burn Down Chart Patterns
  • Business Cases & Portfolio Management
  • Legacy Code Vs Legacy Product
  • Limited WIP
  • Trust
  • Meeting Commitments or Delivering Value
  • How To Get Buy-in to Agile
  • Product Owner?
  • Inertia
  • Marketing and Follow-Through
  • Telling Vs Coaching
  • Ubiquitous Language Does Not Mean Japanese Jargon
  • Defusing The Politics
  • Why Agile is Harder than Waterfall
  • Don’t Ignore Your Environment
  • The Elephant in the Room
  • Broken Windows
  • 5 Whys
  • 6 Thinking Hats
  • Debunk Sessions
  • Risk & Reward
  • 3 Points are Better than 1
  • Desire Lines
  • The Power of Team Casting
  • Using Stage Gates to Your Advantage

*edit* – my first vote is in already from @fatherjack (thanks!) “Telling Vs Coaching” coming up next.

Another edit: Oct 2012 – thanks everyone for continuing to comment and vote. The top 3 items from the backlog by voting/popularity have now been delivered. I’m likely to write a couple of new ideas up whilst they’re fresh and then get back to the requests again!

Swimlane Sizing – Complete & Fast Backlog Estimation

Reading time ~ 5 minutes

Thanks to Adrian Wible for sharing this tip when I was in Nevada a couple of years ago. It’s now one of the most powerful simple tools I have at my disposal. I use it frequently with teams to rapidly size their backlogs and recalibrate their sizing.

This can be used with teams at any experience level but works with least pain if teams aren’t used to story points beforehand.

Teams new to story-points (or even working together) often get hung up on the numbers themselves and instinctively want to start converting to hours, ideal days, elapsed days or similar. The value of story points for teams during estimation sessions is in the relative sizing, not the actual size.

This approach keeps numbers entirely out of the mix until the end and allows participants to focus solely on the relative sizing of stories.

Once we’re over the relative sizing hurdle, adding numbers becomes a straightforward activity.

I’ve done this same activity with electronic tools but I’ll describe the manual version here…


Get your deck of incomplete user stories on readable cards or stickies.

If you also have a couple you have completed, these are useful triangulation points but not mandatory

In a room with your team, get yourself a large flat clear surface. I recommend tabletops in the middle of a space as you can swarm your whole team around all sides – this isn’t so simple with a wall.

Using string or sticky tape mark out 8 “swim-lanes” on the table (Requires 7 lines)

Your table should look something like this.blank table

Don’t put any labels on the swim lanes






Divide the deck of stories amongst your team and ask members to spend a maximum of 5 minutes silently placing their stories in the swim lanes – with stories of increasing size from left to right.  E.g. smallest stories in the left-most lane.

You might want to lead the team through the first 1 or 2 random stories to give them some anchors or triangulation points to work from.

Don’t say anything about story points or numbers, if anyone asks just reiterate we’re looking for size relative only to each other.

If needed; guidance on complete unknown stories at this point should be to assume they are “very large”. The next round of sequencing will allow others to move them if they feel confident in doing so.

Once all stories are placed, you’ll probably have some “clumping” of stories, as in the table here. (assume X’s are story cards).

Give the team 5-10 minutes to again silently move any stories to different lanes where they feel their size relative to others makes them more closely aligned to those in another lane (stories must be wholly in a single lane – no overlaps).

Encourage team members to quickly look at and consider the location of each story on the table.

A team may occasionally find a deadlock where a story is “stuck” moving back & forth between lanes, you may intervene, pull the card out for discussion or allow the time boxing to encourage the card into a single location. Generally if there’s uncertainty, I choose the larger option but the last step of the process will resolve these.

Your table should now look something like the example here.

Once all the cards are placed and reviewed, ask the team to rate their satisfaction/confidence on the relative sizing and placement of the cards (use a scale of 1-5). For any team members indicating a low satisfaction level (1 or 2), ask them to describe their concern and for the team to decide upon how to act (either move a card or validate its current position). Time box this to 2 minutes per team member if possible. Use this opportunity to re-place any deadlocked stories – if a team really can’t decide, be cautious and go for the larger option.

Once relative sizing is agreed with a reasonable level of confidence for the whole team it’s time for a couple more questions.

For all the stories in the left-most column, do you think you’ll be working on anything smaller?

If the answer is “yes”, call this column 3 or 5; if the answer is “no”, call this column 1 or 2 (a single number from these options – use your judgement and instinct).

Now assign remaining numbers across the top of the columns using a subset of the common modified Fibonacci sequence used for story point estimation: (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, !/?)

This will give you a table of stories much like one of the following…







(I usually prefer the far-right column remains unsized to be broken down further to make it clear that this is a coarse exercise and cannot be used for commitments).

That’s it! You’ve just estimated & sized (using story points) your backlog in well under an hour.

It’s coarse, quick and dirty but chances are that even when you learn more, most of these won’t change relative to those in other columns .

More Depth:

The use of “silent sorting” is a powerful practice for agile teams. It removes debate and ensures focused thinking however in this example its use coupled with the lack of numbers is to avoid a common problem with inexperienced estimation teams during planning poker exercises known as “anchoring”. This is where an individual on a team will speak up with their view on what size a story should be before the remainder of the team have selected their view on size therefore influencing and anchoring all others estimates for the same story to a given point.

If you reuse this approach for additional rounds of backlog items I recommend preserving some of the older stories in the swim lanes to provide triangulation points for newer stories. Without these anchors your team’s velocity and estimation may see large shifts and greater unpredictability based on the shape of the new backlog.

Teams will quickly get used to which numbers match which lanes. This practice is still valuable however you may need to encourage teams to remain focused on relative sizes and not the numbers.

I generally hold the following views (and have found these actually do transfer well across teams)

  • 5 is typically a “medium” sized story for a sprint
  • Anything greater than 8-13 requires further decomposition
  • Seriously consider also decomposing stories of size 8-13
  • Anything greater than 20 is in reality an unknown needing further investigation and decomposition before it can be sized sensibly.

These views can in themselves anchor others’ estimates towards some specific numbers. As a facilitator an awareness of the range of numbers used and their meanings is useful but be cautious that this information does not influence the outcome of the team’s process.

Update: March 2015 – 4 years after posting this article it’s still the second-most viewed page on the site. I’ve now added a second article offering some more theory to help explain how swim lanes and story points hang together with traditional estimation concepts.

Dietary Manipulation (Part 2) – Carbo-Caution

Reading time ~ 2 minutes

My first article on dietary manipulation was intended to be the last. However as I learn, so I must adjust…

Some time ago I had the pleasure of guiding a team through a backlog prioritization session – taking items from a large unsized, unordered backlog down to a subset that we believed could be achieved in a short window of time (either in the next 6 weeks or to the end of the summer).

I had the benefit of free lunch in the staff canteen. At the time I wasn’t sure if the food selection was normal for the site or if it was just an end of the month special – either way, the food was very good. Although there were salads and yogurt, it was frighteningly easy to load up on a mountain of well-prepared comfort munchies.

The session I was running was scheduled for about 2-3PM.

Can you see this coming?…

Remember how I previously loaded a team up on carbs so my audience would hit their low-ebb during a difficult patch?

When I’m leading a workshop with an unfamiliar group I’m not very good with pauses & quiet periods so I tend to fill in the gaps (I already know it’s a weakness for coaching). Despite the mix of comfy armchairs and the post-lunch downturn, the team did a great job. They were very tolerant of my ad-libbing and ran the exercise in really good faith but even so it was really hard work for me.

The good news is we achieved our goal in just under an hour. A small, actionable, prioritized set of “must do” items for the team to dedicate some time to clearing before the end of the summer.

Next time, I’ll try loading up with fresh coffee and see what we can get done in 30 minutes and before everyone needs a bathroom break 🙂

Epilogue: – I’ve just started working with this team full-time. The food is that good and the team are that accommodating all the time.

Must try to remember… No mid-afternoon team workshops. Oh and …must… …stick… …to….  salad & smoothies.

Well – sometimes.

Learning to Say “No”

Reading time ~ 2 minutes

The great thing about working with software development teams is that on the whole they’re a nice bunch of people who just want to get on and do the right thing.

The tricky thing in large-scale enterprise product development is that there’s often aggressive targets pushed through sales & marketing onto product managers.

A common response is to take a shotgun to the enhancement request backlog and ask for everything from the development teams and negotiate down from that point.

Craig Larman & Bas Vodde summarized this brilliantly using game theory in the second of their scaling agility books as the “your fault” game.

Assuming like many large companies you’re faced with the challenge of an annual commitment-based project/backlog and you’ve whittled that down to the best you can do; chances are your product manager will come back at some point through the year having visited a customer or partner and, like Columbo, ask for “just one more thing”.

Agile development is meant to give us the flexibility to do this right?

The typical nice guy response is “well… it’s going to hurt … but we’ll try”…

Great! When your team gets kicked around the room at the end of the year for failing to meet their release commitments, I’m pretty sure I know whose “fault” it’ll be.


So… Time to dig yourselves out of that abusive relationship, get a backbone and learn to say “No”.

OK. Maybe that’s a bit harsh. How about…

“Sure we’d absolutely love to do that but here’s everything we’ve already committed to for you. What would you like us to drop first?”

That still sounds pretty collaborative – but now it’s on your terms.

You’ve also just highlighted that being Agile doesn’t mean not making commitments if that’s what your business needs, it means managing your customers better.

If the previous “we’ll try” conversation is the norm for your teams, chances are this is the first time your product manager has ever been put in this situation. Don’t expect it to be pretty or easy. You’ll need to stand your ground and limit the options available.

I’m a fan of visual management so here’s my take.

  1. Take all the features you’ve committed to already and put them on cards or stickies.
  2. Draw a box around them so that there’s no room for anything else.
  3. Bring your product manager to the table, hand them the new feature or item they want on a card of similar size to an equivalent feature.
  4. Ask them to trade out something so that the card fits.
  5. Once the trade-out decision is made. Confirm any timing impact on the other features.
  6. Optional… (but recommended If you’re in a low-trust environment) Get the decision in writing recorded in whatever your system of record is.

If you can’t get your product manager in the room, do the same thing with excel and coloured blocks representing each feature in a pipeline. Adding a new feature in anywhere in that pipeline extends the end date. If you’re on a fixed-date commitment that means something falls off the end.


Give this a try or adapt something similar for your own needs.