How to Improve your Pointing using The Pointing Mantra

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

morph

“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.


How to do Sprint Planning

It’s the top of the sprint. The backlog is prepped. The stories are all pointed. Everybody is raring to go.

Let’s plan!

Asleep Meeting

Oh my. Planning sessions are hard. They’re hard for all sorts of reasons, generally bad ones. Here are some characteristic antipatterns from planning sessions which I have both attended and run in the past:

  • They are way too long – like, spirit-crushingly long – I actually almost resigned at the end of one planning session, so depressing had it been
  • The highly verbal minority drive the thing – the same few people push the agenda each fortnight
  • It is very draining doing deep technical dives on a variety of subjects in quick succession
  • People revert to classroom mode (giggling, chattering, falling asleep)
  • The meeting has little value for non-developers – the Product Owner / Customer and even QA people are left somewhat out in the cold as various forms of technical noodling unfold

It’s pretty clear that Sprint Planning has a very great capacity for becoming the low point of the sprint cycle. This is a massive shame since it is at the very start of the sprint!

So, when I took over as Head of Tech at my most recent firm, we opted for a different approach. We use the Sprint Planning session for two purposes, neither of which are tech planning:

Firstly, we use it to confirm with the Customer which stories are in the sprint. This is a very brief process since (a) our Product Owner is organised and has prioritised in advance and (b) we don’t waste time bartering menainglessly over Points Commitment since we use the points bagged in the last sprint as the Commitment in this one.

Secondly, we use the session to write the Customer Test Scenarios for the top priority stories. We do not go any deeper than this. We aim to list the scenarios, and fatten those scenarios up with the pre-conditions (@given steps), the test actions (@when steps) and the post-conditions (@then steps) [We are using the Python Behave behavioural testing language - see here for details of how]

We also don’t do this to death. We do this for just enough stories to fill the next few days. We then do “just in time” planning during the rest of the sprint. This keeps the stories fresh, keeps the planning sessions as close to development time as possible, and reduces the exhaustion factor in the Sprint Planning session itself.

Some of the benefits of this approach will be immediately apparent to you, benefits such as:

  • Keeps everyone involved
  • Avoids tedious technical posturing / competition
  • Keeps the focus on testing 

However there are other, more subtle benefits which fall out of this which really help with the biggest problem factors in development: human interpretation and implicit assumptions. To see what I mean, first consider these two versions of events for the same story.

Story: “As a site user I want to be able to search for employees by first name and last name so that I can locate people’s data without having to know their employee number”

Version 1 – Sprint Planning focused solely on technical planning

Takeaways from session:

  • Add indices to those 2 columns
  • New URL / view setup in Employees app
  • Handle mid-word searching (e.g. searching for ‘mit’ returns all the Smiths)
  • Show number of returned results on the screen
  • QA to confirm tests with Customer tomorrow

Sounds pretty sorted, right? I can see this story going well. Or rather, I can see it going well until I compare it with the takeaways from the “Customer Scenario Writing” style of Planning Session:

Version 2 – Sprint Planning focused solely on Customer Scenarios

Scenario: I can search on any part of a name

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘mit’ in the search field and hit enter
  • Then I see only John Smith and Joan Smith
  • And I see “2 employees found”

Scenario: I can enter more than one term and if I do, each result should contain all of the terms:

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘oh mit’ in the search field and hit enter
  • Then I see only John Smith
  • And I see “1 employee found”

Scenario: End spaces and spaces between words should be stripped out

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘  oh   mit    ‘ in the search field and hit enter
  • Then I see only John Smith

Scenario: Clearing the search field resets the search results

  • Given we have John Smith, Priya Patel, Joan Smith
  • When I enter ‘  oh   mit    ‘ in the search field and hit enter
  • And I click the ‘X’ in the search field
  • Then I see John Smith, Priya Patel and Joan Smith
  • And I do not see “employee found” or “employees found”

Scenario: If no records match then I want to see a polite message and an empty result set

  • Given we have John Smith
  • When I enter ‘foo’ in the search field and hit enter
  • Then I see ‘No employees match your search’
  • And I do not see any employees
  • And I do not see “employee found” or “employees found”

I bet the team from the first version of events missed at least one of those. I also guarantee that everyone who was at this second session is in no doubt as to how the feature works. Developers, QA people, even the Customer accepting it – especially the Customer accepting it: At least 2 of those points (the second and the fourth) are things which classically a Customer would not think up until the first demo, which in theory is a bit late in the day to be rethinking some of the ORM/database layers. Writing these Scenarios as a group means that we have already bridged the human gap for this particular story, and we haven’t written a line of code yet! We have also ensured a much more ‘luxurious’ user experience and avoided that ‘unfinished’ feeling which many new releases often have.

A further benefit of this approach is that these style of scenarios lend themselves very well to doing the actual development in proper, bona fide, Kent-Beck-Approved Test Driven Development. Your team truly is writing software from the outside in, which means the tests are written from the outside in. Compare that with the classic approach of writing from the database outwards: Talk of database indices, manager methods, boolean operands, blah, nowhere to be seen yet. And rightly so! We are Agile; We deliver working features, not code which we then bend to provide those features. Even better, our Customer Tests and our Dev Tests describe the thing we are building – a massive help when we come to refactor / alter things in the future. Imagine the tests which fall out of these scenarios naturally, then compare them with the sorts of mechanical, restricting unit tests you get supporting dev tasks like “add 2 indices”. Our tests here will be much more organic and useful to future coders.

Finally, it also means that you only write what’s necessary. There’s no scope here for some time-wasting, generic SuperBooleanMultiColumnSearch object, written “in case we need it later”. Nope, you’re just delivering something that hits those 5 scenarios. Job done, onto the next thing. Agile.

Intro: Putting It All Together

At the time of writing, it’s eleven years since the signing of the Manifesto for Agile Software Development. That’s a long time.

In that time, much has been done to try and introduce Agile successfully as a standard development practice (for some values of both “try” and “successfully”). Most times however, you will see Agile implemented as a kind of loose mish-mash of “we do 2 week sprints” and “we use stories” and “we have daily standups”.

There are two honking great problems with these piecemeal approaches. The first problem is that you can’t just cherry-pick your favourite ideas from the Agile principles (unless it’s git cherry-pick hohoho etc) and the second – less obvious – problem is that these doomed attempts are clearly only being applied at a dev team level. That is to say that they suffer from 3 enormous and fatal shortcomings:

  1. They don’t actually address any practices that take place at a coding level or a knowledge-sharing level in the dev team
  2. They provide no conduit or mechanism to ensure that the stuff built is the stuff that’s actually wanted
  3. They say nothing about the rest of the up-line business, or the idea of long-term product plans, deciding what will be worked on during this sprint, next sprint, in 3 months’ time, etc.
So in this way, most current attempts at “doing Agile” focus purely on the middle layer, and fail utterly to comprehend the required behaviours needed both upstream,  in the commercial parts of the business, and downstream, in development practices.
 
Often businesses can get away with this – particularly those small startup pods that are essentially funded software research projects. However, while so many play expensively at being the next Page/Brin combo, there is a real need to plug a practical gap and start sorting out companies whose product lines are actual, functioning software. These guys are still thrashing around with late-running projects, unhappy customers and long-lasting bugs. It doesn’t seem to matter how smart their teams are; they still have these problems. The so-called “enterprise” toxic bloatware pedlars have had a stranglehold on this capable, organic sector for too long. It’s time for businesses everywhere to realise that the future is Agile with SCRUM and XP, and that the tools required to make this happen are necessarily Open Source and not “enterprise” – because of the very reasons Open Source exists.
 
That’s what this blog is about. It will aim to show that the only workable, reliable delivery stack for software provision in real businesses is:
  • Commercial Schedule: Agile
  • Product Owner: Agile
  • Devs sprint-by-sprint: Agile/SCRUM
  • Devs day-by-day: SCRUM
  • Devs hour-by-hour: Extreme Programming

In this model, Agile is a common conduit from Commercial Schedule through to the developers’ sprint involvement but from there on in, SCRUM is a handover mechanism on a daily basis, down to the hour-by-hour, blow-by-blow, key-by-key use of Extreme Programming. It is this handoff, this synchronisation of differently sized cogs, which makes for the truly “Agile” approach.

That’s what is meant by “Putting It All Together”, and that’s what this blog is about.