It’s the top of the sprint. The backlog is prepped. The stories are all pointed. Everybody is raring to go.
Let’s plan!
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.
Software's About People 