user stories

Benefits of Value Poker (2 of 2)

Last time I described how to estimate value on story cards. Now, lets talk benefits. Ultimately, the real value of this game is the conversations it creates. But along the way there are plenty of other benefits. The licensed dissent the game allows creates many insights and ideas.

The most obvious benefit of Value Poker is simply: at the end of the game you have a value based priority order. A team could, simply, take the highest value story and start work on it, deliver it and move on to the second highest. What could be better?

But actually, having value on the cards brings many other benefits and creates many options. For a start, having thought about the value of individual pieces ones perspective on the work to be done changes. What looked like a large chunk of work, a single monolithic product, might look like a stream of valuable features.

Value beats how-long

Moving the conversation away from “how long will it take” to “what value will it create” provides a whole new perspective. One which many have never appreciated before.

Rather than simply start at the highest value and work down conversations about the order of work become more than just technical “A depends on B.” One can think of value dependencies: customers can only get high value A they also have low value D. In which case, is D really a distinct thing, or is it part of A?

Both technical and business dependencies are exposed. All sides get to see why doing the most obvious thing might not be the right thing to do. The team might consider how else they may unlock the high value story without the need for the low value story. Maybe a subset of low-value D should be included in A. And maybe the rest of D isn’t worth doing.

Sometimes these insights only appear because teams are able to be adversarial. In most work environments people show respect. If a Product Leader ask for something few would openly say “That is pointless” or “Why would you do that?” but when playing Dragon’s Den people are allowed to openly question and think-outside-the-box. Indeed, since many have seen the game show people naturally fall into the roles and need little encouragement to challenge ideas. It becomes easy for a lowly engineer to say “I don’t see the market for this” or “Why would I buy this when product XYZ does that?”

Better than Word and PowerPoint

This in turn leads to two more benefits. First the Product Leaders need to be clear about what they want, why they want is and why they see value. They can’t hide behind PowerPoint charts or long business plans, they need to explain their point and defend their position in real-time. Product people are made to up their game.

People sometimes say to me “These two stories can’t be compared, they are like apples and lemons.” But money – even fantasy money – is a great leveller, it measures such asymmetric things. After all, the money you get paid for labouring over a hot keyboard each day can be used to pay your rent, buy a beer or take a holiday. How else could you compare the value of having a roof over your head with drinking beer?

This approach allows everyone involved to have a say. All the brain power in the room, all the knowledge, all the neurodiversity, can be exercised and used. New ideas, start flowing. Dragons and Product Leaders frequently see new or missing features which could be included enhancing innovation benefits.

In one game the Product Leads were proposing an app based around lunch time food trucks. They pitched story after story to the Dragons who gave it low value. The idea didn’t fly. After a quick consultation the entrepreneurs switched from pitching stories with benefit to food truck operators and pitched on Hungry Jo customers. The valuations rocketed. This is where the value was.

With all the discussion, the challenge, the reply, the adjustment something else happens: everyone builds a great shared understanding of what the product is supposed to do, how the entrepreneurs see it being used and who the target audience is. It becomes a great way to understand requirements and specification – far better than reading a dry document or even a PowerPoint presentation. This is why even playing this game with the engineering team can be highly rewarding.

Scheduling to maximise value

Believe it, or not, giving the stories a value can also help with scheduling – even without effort estimates. Once a story has a value one can ask “If this story is work 100,000bp today, what is it worth next month? in six months? in a year?” If the value never changes then the story can safely be postponed indefinitely because the value is always there. If on the other hand the values falls rapidly then the story needs doing soon. Sometimes, there might be more total value from doing a low value story (which will loose value soon) before doing a high value story which will hold its value.

Some readers will notice this is the start of a cost-of-delay conversation. One might now start to talk about Time-Value Profiles. Equally, only when you have value on individual work items can you really start doing cost-benefit, and biggest-bang-for-your-buck, analysis.

Finally, one big benefit I hope you’ve realised along the way: this game is a lot of fun. Not only does it help teams understand but it helps teams bond.

Want to play?

If you would like me to run this game for your company or your user group or meetup please get in touch.

Benefits of Value Poker (2 of 2) Read More »

10 rules of thumb for User Stories

There is a universe somewhere in which my blog is always on topic, I have a theme and I always produce posts which accord with that theme. However, in this universe my mind flits around and, for better or worse, this blog carries what is on my mind at the time. Sometimes that is grand strategy, sometimes hands-on-detail, sometimes the nature of digital work and sometimes frustration.

This week I’m dusting off my slides for next months User Stories workshop so I thought I’d share my User Stories 10 rules of thumb:

1 – Stories are usually written about a hands on user, someone who actually puts their hands on the keyboard

2 – If your story begins “As a user” then save the ink and delete the words, “as a user” adds nothing. “As a customer” isn’t a lot better. In both cases think harder, come up with a better “user”. Be as specific as you can.

3 – Stories which have systems in the user role should be rethought (“As Order Entry System I want the E-Mail System to send e-mail so that I can notify the humans”). Step back and think “Who benefits from System-E and System-F working together?” then rework the story with that person in mind seeing a combined system (e.g. “As a Branch Manager I want e-mail notifications sent when an order is entered.”)

4- Stories should be big enough to deliver business value but small enough to be complete in the near future, I’m prepared to accept a maximum of 2 weeks but others would challenge that and say “2 days is the max.” (Small and valuable actually constitute my 2 Golden Rules, where I also discuss Epics and Tasks.)

5 – There is no universal right size for a story. Teams differ widely in terms of the best (most efficient, most understandable, quickest to deliver, biggest bang for your buck…)

6 – In general the greater the gap (physical distance, cultural norms, history working in the domain, employment status, education level, etc. etc.) between the story writer (e.g. BA) and receiver (e.g. Tester or Coder) the more detail will be expected by one side or the other.

7 – If the User Story format “As a … I want to … So that …” isn’t readable then write something that it. Who, What and Why are really useful to know and he standard format usually works well but if it doesn’t write something that is. There are no prizes for “the perfect story.”

8 – Beware stories about team members: a story which begins “As a Tester I …” or “As a Product Owner …” are red flags and should be questioned. Unless you are actually building something for people like yourselves (e.g. a programming team writing an IDE) then stories should be able end users and customers. Very very occasionally it can make sense to write something for the team themselves (e.g. “As a Tester I want a log of all database action so I can validate changes”) but before you accept them question them.

9 – Stories should be testable: if you can’t see how the story can be tested think again. If you are asked to complete a story which you can’t test then simply mark it as done. If it can’t be tested then nobody can prove you haven’t done it. However, in most cases someone will soon report it as not working and you will know how to test it.

10 – Remember the old adage “Stories are a placeholder for a conversation” ? Well, if you have the conversation all sins are forgiven. No matter what the flaws are if you have the conversation you can address them.

Needless to say more about these topics in Little Book of Requirements and User Stories.

Now just because I go around saying radical things like “Nuke the backlog” does not mean I want to ditch the wonderful who-what-why structure of user stories. You might throw away a lot of user stories but when thinking about the work to be done in the post-nuclear supersprint then by all means: write user stories.

10 rules of thumb for User Stories Read More »

User Stories are not Story Points

Funny how somethings fade from view and then return. Thats how its been with User Stories for me in the last few weeks – hence my User Story Primer online workshop next month.

A few days ago I was talking to someone about the User Story workshop and he said “O, I don’t use Story Points any more.” Which had me saying “Erh, what?”

In my mind User Stories and Story Points are two completely different thing used for completely different purposes. It is not even the difference between apple and oranges, its the difference between apples and pasta.

User Stories are lightweight tool for capture what are generally called requirements. Alternatives to User Stories are Use Cases, Personas Stories and things like the IEEE 1233 standard. (More about Use Cases in the next post.)

Story Points are a unit of measurement for quantifying how much work is required to do something – that something might be a User Story but it could just as easily be a Use Case or a verbal description of a need.

So it would seem, for better or worse User Stories and Story Points have become entangled.

The important thing about Story Points is that they are a unit of measurement. What you call that unit is up to you. I’ve heard those units called Nebulous Units of Time, Effort Points or just Points, Druples, and even Tea Bags. Sometimes they measure the effort for a story, sometimes the effort for a task or even epic, sometimes the effort includes testing and sometimes not. Every team has its own unit, its own currency. Each team measures something slightly different. You can’t compare different teams units, you can only compare the results and see how much the unit buys you with that team.

To my mind User Stories and Story Points are independent of one another and can be used separately. But, it is also true that both have become very associated with Scrum. Neither is officially part of Scrum but it is common to find Scrum teams capture requirements as User Stories and estimate the effort with Story Points. It is also true that Mike Cohn has written books on both and both are contained in SAFe.

Which brings me to my next post, User Stories v. Use Cases.


(Images from WikiMedia on CCL license, Apple from Aron Ambrosiani and Pasta from Popo le Chien).

User Stories are not Story Points Read More »

How fresh is your backlog?

Do you struggle with an overwhelming backlog?

Do you count the number of product backlog items in your backlog in tens? hundred? or thousands?

Does your backlog contain many stories which have been there for months, if not years, and yet never raise to the top of the backlog?

Is your success judged on your ability to do the backlog?

Backlogs were a good idea when they were introduced a bit over 20 years ago but today many teams slaves to the backlog – see my posts on the Tyranny of the backlog and Purpose over backlog. One of the benefits I’ve called out for OKRs is the ability to move away from backlog driven development (BLDD).

In Succeeding with OKRs in Agile I ask suggest you either need to prioritise your backlog over OKRs (in which case OKRs are derived from the backlog you intend to do) or OKRs over backlog (in which case OKRs are derived from strategy and the backlog plays a supporting role.) In my podcast with Jenny Herald earlier this year I even say “Let OKRs drive… nuke the backlog.”

Filipe Albero Pomar recently shared his backlog freshness blog which I think is great. Freshness is a great way to think about the state of the backlog that separates the size of the backlog from the relevance of the backlog.

Filipe’s idea is simply to talk about the backlog in terms of freshness – you have a fresh backlog if your backlog items are fresh: written recently, relate to current opportunities, problems and things people currently want.

And of course, the opposite of fresh: stale, stories that have been sitting in the backlog for months, even years, stories that relate to yesterday’s problems and project, stories which people wanted last year. The existence a big backlog of stale stories means the team is seen to be not delivering, the end-date is far off because people still expect all the work to be done.

Filipe suggests backlog freshness can be measured:

1. Set a cut-off date

2. Categorise stories as fresh or stale: fresh stories have been written since the cut-off date, those which are older are stale

3. Calculate freshness as a percentage of fresh from the total: if 25 stories out of 60 have been written in the last month then the backlog is 41% fresh, and 59% stale

Thats a useful metric, I think we can do better, look at the graphic above. I group backlog items into age groups and graphed them. For completeness I added a line to indicate average story age. Clearly this backlog is not fresh – nearly half the stories are over a year old.

I like the idea of graphing backlog freshness because it is easy to understand and makes an impact. In the graph above I’ve categorised backlog items into age groups and added an average line. Clearly this is not a fresh backlog. Whether this is the way to demonstrate backlog freshness I’m not sure – I’m playing with a histogram and quartile ranges.

With some clients I’ve thought of the backlog like a mortgage. There is the principle (the existing backlog), the interest rate (the growth rate of the backlog) and the monthly repayments (stories reaching done). Unfortunately when you do this you sometimes find the mortgage will not be paid for many years, and perhaps never. (Don’t worry about estimating the size of stories, for this sort of analysis the number of stories will get you started, and if your backlog is measured in hundreds of items the small will offset the large.)

I’d love to talk more about this and experiment with some ideas, I think it could be a very useful way of thinking about the backlog.


Subscribe to my blog newsletter and get Continuous Digital for free

How fresh is your backlog? Read More »