Improve Your Pointing

Unless you are spectacularly lucky, your pointing process needs help. Recently in our team, we developed The Pointing Mantra to help soup up our pointing a bit. Using this we have been able to:

• Double the number of stories we can point in any one session
• Remove virtually all confusion and “surprise” from stories as they move through the lifecycle

This article will describe why pointing needs to completely optimised, and will show you the steps we take at every pointing session to make sure we get as close to “completely optimised” as possible.

Why? Because pointing REALLY matters

Even if your stories came from a workshop (which really they should have done) then pointing is the first time everyone really gets their thinking caps on. If your stories didn’t come from a workshop then this will be the first time that the dev team and the Product Owner have looked at the story together.

Pointing is the last time the story can be altered and/or split up and because it is the story which is the primary unit of work in Agile, and because it is the story which represents everyone’s perception of the work to be done, then the story needs to be as clear, well-formed and unambiguous as possible.

The story is the most crucial component of the Agile process. The difference between a stream of well-formed stories and a stream of ticking time bombs is pretty subtle and not always obvious to most people at first glance. But worry not! The Pointing Mantra is on hand to make this process far more smooth and more automatic than you thought possible.

The Mantra is included in full at the end of this post, but first here is is, in breakdown, with an explanation of each stage.

For the purposes of this exercise, we will work with a real-life story from a project I am currently involved in. Here’s the original story content:

ORIGINAL STORY: As an employee, I want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown, so that I can see clearly at a glance in a single page everything I need to manage my holidays.

Don’t worry too much about taking that all on board – we will break it down in the coming sections. Just read it and note in your mind how the story “feels” when you start thinking about it.

The Four Steps of the Mantra

1. “Storify” the Story

This is the first step and is absolutely crucial to get right. Pride needs to go out the window at this early stage. Whoever wrote the story is going to have to face the fact that, until they are very experienced, they probably won’t be getting it right first time. A great Product Owner is one who can express the needs of their users very clearly but leave their emotion and pride out of it. Not easy, but it needs to happen.

So, at the pointing session, the Product Owner and the dev team should ask themselves this question first:

Who’s the Actor?

Firstly – the ACTOR. Who is the ACTOR? You need to picture a little model dude, a bit like… this guy

“HI, I’M THE ACTOR”

You have to be able to picture this actor and know how they move, how they talk, how they tick. This is a direct link to the User Profiles you would talk about at a Story Workshop. When it comes to the story, these ladies and gentlemen are your actors. They are embodied in the story text within the “As a …” clause. Getting the actor right is crucial before the next step.

What’s in their Speech Bubble? Can you imagine THEM saying it?

Now, picture a little speech bubble coming out their mouth. In that speech bubble are the words “I really want to….” followed by whatever the actor wants. It has to be – and this is the real litmus test – something you can imagine the actor saying out loud in their own language (or something that you can imagine them thinking to themselves in the event that you are dealing with actors who do not actually speak IRL).

Start by just lifting the “I want to…” clause straight off the story card, and prefix it with “I really want to..”

Here is the “I want to” phrase from our original example story, with “I really want to” added at the front.

Version 1: I really want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown

I cannot actually imagine a regular employee saying this. By prefixing it with the pseudo-childish “I really want to” we can easily expose those stories which are subtly disguised specs and, of course, specs are BAD.

Closing your eyes and picturing the little actor guy in your head, you may get something like this instead:

Version 2: I really want to know how much more holiday I have left to book in any given year

Once you’ve got this straight, there’s your “I want to” story clause, which you can edit back into your story card. You may have already spotted a potential story split already in that second version – we will talk about that later. The important thing to note here though is that we have captured the extra scope of the first version (namely the varying years idea) in that second version, but with less spec-like detail.

Ask the actor WHY

Getting a clear answer from your imaginary actor will help you in two really important ways. First, it will enable you to prioritise the story better, and secondly it will make clear to you the nuances of this story which will elevate it from an acceptable solution to a GREAT solution.

What’s important is that we give them what they want, not a description of the system which behaves in a certain way to give them what they want.

Here’s the “so that” clause from the original story:

“…so that I can see clearly at a glance in a single page everything I need to manage my holidays”

Sounds OK, right? Got value, right? Well, yes and no. While there is undeniable value in (a) being able to see and (b) being able “to see in a single page everything blah”, I don’t think it’s what’s motivating the actor to speak their line. So go ahead, ask the little guy in your head: “but WHY do you want this, fella?”. In our real life work with this story, we did that and we got the following answer:

“…so that I can plan my holidays efficiently and with minimum fuss”

Now, that is a country mile away from “seeing at a glance blah”. These users will be planning holidays, organising personal time with the permission of their employer. Just pause for a second and think of the nuances of that second picture. You can really help them to get their vacation all sorted and organised if you get this screen right. Planning holidays and trying to synchronise a booking with time off work is pretty stressful as it is, and we can really help them here. This is how you move a story from being an acceptable solution to a GREAT solution.

Once you’ve got this piece of the puzzle, edit that back into the original story as well.

The Storified Story

So, here’s our newly-storified story: 

“As an employee, I want to know how much more holiday I have left to book in any given year, so that I can plan my holidays efficiently and with minimum fuss”.

It’s already looking better. Now onto step number two.

2. Can we split this story? Then split it.

Not “should we?” or “are we allowed to?” or “is it OK to?”. Nope. “CAN we split it?” It is a fact that smaller stories are easier to manage and leave more space in their planning and execution (and, as discussed above) for the subtle nuances to creep in which make the difference between an adequate feature and a great feature.

Now, spin back a sec to the previous section – “Storify the Story” – and, in particular, the idea of the speech bubble. Let’s look again at those 2 versions from above, firstly the version we discarded…

Speech Bubble Version 1: I really want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown

Can you split version 1? I don’t know. Give it a go for a second. Can you? Maybe. I don’t know. It makes my head hurt. A pointing session with several of these in is going to be a pretty shitty start to the day.

But look! With version 2 it’s simple:

Speech Bubble Version 2: I really want to know how much more holiday I have left to book in any given year

Don’t forget: we are looking to split the story. We WANT to split the story. So, with that in mind, this second version sounds downright unnatural with that “in any given year” on the end. It almost belongs in parentheses to be honest. Forcing your story’s “I want to” clause into the language of the actor has forced this optional complexity to the surface. So, yes! We can split it, and split it we shall.

This gives us 2 stories for the same actor, each with its own speech bubble.

Story 1 Speech Bubble: I really want to know how much more holiday I have left to book this year

Story 2 Speech Bubble: I really want to know how much holiday I can book in future years

We created that second bubble by lancing that ugly “in any given year” off the end there. You will note here that the logical third speech bubble – “I really want to know how much holiday I can book in past years” – isn’t mentioned because, of course, it makes very little sense. Again, through simplifying our language we have exposed needless scope and eliminated it. If we had ever played the story in its original format, I can imagine that dev time would have gone into getting a previous/future years navigator going, some of which would have been a total waste of time.

Of course, those 2 stories should be pointed separately, and the second one needs to go back through this whole process again, starting at the first step. For now, we will press on with the first story alone.

Right, splitting is done. On to the next step…

3. Does the story have a definite,  SINGLE ENDING that an ACTOR can see (and TEST for)?

Tests. Remember? We will be expressing everything in terms of Behaviour-Driven Scenarios, when it comes to our sprint planning session. So, each story needs to have an end-point which we can easily and unambiguously test for.

With our example story, this is pretty easy – the actor (the employee) will see an accurate summary of remaining holiday on the screen. But this step isn’t always so easy – however you must ensure this is the case. This is even more specific than the usual insistence that there be “business value”. That’s such a vague term and very, very subjective. So instead of this mythical “business value”, let’s remember that we are implementing experiences rather than implementing systems, and focus on each story having an end-point which an ACTOR can SEE.

• Beware false end points such as “we can see the system is now configured to do X” – this is merely a spec in disguise (and not a terribly effective disguise, either)
• Beware the terrible end-point “..and we can see the record in the database”. Unless your story is “as an admin I want to be able to hand-edit data” then this is not an endpoint. Worse, it is the opposite of Agile – your story planning will require that you define the data model spec as part of the planning. Eurgh.

Nope, you need an endpoint that an actor can see. It might not be the same actor, but it needs to be a human, a recognised user. You may even need to put in a super-lite screen to handle this. (For example, a story about “requesting holiday” will probably necessitate that you put in a lite, dumb “all holiday requests waiting on the system” screen to provide an endpoint – if so, add it).

4. OK. Point!

Now – and ONLY now – go through your “democratic pointing process” – whether you use fingers in the air, IM votes, dopey playing cards or whatever. Those digits or chat windows or risible upsell items should have remained unused until now.

But before we point, let’s look at the stories we are now pointing and compare them to the original. Here’s the original story:

ORIGINAL STORY: As an employee, I want a quick summary of my holiday details, by holiday year start date (defaults to current holiday year) with a holiday balance for the chosen year and holiday records shown, so that I can see clearly at a glance in a single page everything I need to manage my holidays.

Now, just pause for a sec and imagine actually trying to point that. Don’t spend long, just… probe the thought. Poke it with your finger. Feel the resistance. OK. Here are our two, new, storified, split and end-pointed stories (with the component sections assembled back into normal story format):

NEW STORY 1: As an employee, I want to know how much more holiday I have left to book this year so that I can plan my year’s holidays efficiently and with minimum fuss

NEW STORY 2: As an employee, I want to know how much more holiday I have left to book in future years so that I can plan long-term holidays efficiently and with minimum fuss

Now imagine putting points on those. Every team’s points scale is different, but I reckon they’re both small and the second is probably about half the size of the first. And how did that pointing thought process feel? Pretty easy. Repeat that for 6 or 7 other stories in a pointing session and you’ve still got the will to live and the energy to get stuck into your dev work for the day.

And – as you may have noticed – straight away those stories are dead easy to prioritise. New Story 1 is clearly a “Must Have” – it’s a high-volume, high-personal-value, used-daily feature. Bosh, straight to the top of the pile. The second story, although arguably important (and of increasing importance when the current year is getting old) is clearly not as high-priority as the first. No argument.

What You Got from The Mantra

The whole point of having this as a mantra is that it is easy to follow, easy to remember, effortless to work with. By following those 4 simple steps, you got yourself:

• A much clearer story content
• Everybody aligned on the nature and value of the experience
• Obvious split-points appearing before your eyes
• Clear priority differences appearing before your eyes
• A pointing process which didn’t hurt
• Stories which will have clearly testable end-points and therefore clear, unambiguous development goals (thus reducing the problem of human interpretation – and Software’s About People, right?)
• Stories which will be GREAT solutions rather than adequate solutions

Finally… Thanks for reading. Here’s the Mantra, on its own. Feel free to copy n paste to a more convenient location for your team’s reference at every pointing session. We open this document at literally every pointing session and not only have we doubled the number of stories we can point in any one session, we have virtually no confusion creeping in at the later stages of the story lifecycle.

The Pointing Mantra

 

1. Storify the Story

• Who is the ACTOR? [Get the “as a….” clause]

• Do we KNOW the actor? [is the user profile in place?]

• What’s in their SPEECH BUBBLE? “I really want to…” Is it telling us THE WHOLE STORY?

• Can you imagine them saying this for real? – i.e. have you used the actor’s OWN LANGUAGE? [if so, there’s your “I want to” clause]

• Ask the actor “WHY“? [to get the “so that” clause]

2. Can we split this story?

• If yes, STOP, SPLIT, START AGAIN.

3. Does the story have a definite,  SINGLE ENDING that an ACTOR can see (and TEST for)?

• could be the same actor, could be someone else). If no, may need to ADD TO the story.

4. OK. POINT.