The sprint planning meeting is a key ceremony in the sprint process model, and ensuring that the right level of scrutiny is applied to the planning process is a vital factor in determining agile team success.
Sprint planning happens on the first day of a new sprint and is about negotiating a ‘contract’ between the product owner and the agile team about what scope will be delivered in that sprint. Typically this happens in two stages:
- The ‘What?‘ stage. The product owner comes to the planning meeting with a list of user stories that they would like the team to address in the next sprint. Ideally the user stories will be clustered around or more themes so that the best aggregated business value can be obtained from the sprint. The product owner and agile team then proceed to review the user stories to ensure that the business purpose of each story is understood and the quality expectations are clearly defined. Best practice has it that the team can reject a story if they feel that the requirements are unclear or the scope is too large. The primary outcome of this stage is to identify a set of ‘candidate’ user stories that the agile team will take away to examine in more detail to decide whether all or just some can be completed in the sprint.
- The ‘How?‘ stage. Taking the list of ‘candidate’ user stories the agile team start to examine each in turn in far more detail to better understand the implementation effort. This analysis can be completed in a variety of ways but generally each story ends up being decomposed into a number of ‘things-to-be-done’ which in total quantify the overall implementation effort. After completing this work analysis across all the candidate user stories the agile team report back to the product owner with a view about how many of the candidate user stories can genuinely be delivered in the upcoming sprint. This last qualification is important – the team should only accede to a user story scope that they fully commit to delivering. No ‘stretch goals’ here, it’s about affirming predictability on business value delivery. This might be all or just some of the candidate user stories, and in the latter case further discussions are required with the product owner to decide what stories are to be dropped out of the sprint scope.
Having worked in multiple agile environments it’s my considered view that the sprint planning ‘How?‘ stage represents one of the biggest stumbling blocks to teams successfully working with agile methods. The primary reasons being:
- Planning is hard. You are working with imperfect information and a bunch of often questionable assumptions. In some agile quarters that makes planning pointless, but unless you are working for a software business with very deep pockets then a project’s commercial constraints make planning a basic necessity.
- Developer paranoia. A lot of software developers think of planning as a type of ‘police action’ where their feet will be held to the fire if things turn out differently.
- Developer myopia. Not everybody can see the big picture, and developers have a reputation for not delivering what’s required.
- Developer enthusiasm/rush to get going. Most people are in the software business because they like building things, and as a consequence the boring planning stuff gets short shrift.
Getting the planning step wrong will have serious implications:
- The sprint scope is put at risk, undermining confidence in the team and project.
- An over committed team will scramble to make the deadlines, and in those circumstances quality is nearly always negatively impacted
- Not making deadlines Impacts morale.
Ultimately this is a work identification/organisation problem and when it comes to doing planning well various workplace optimisation gurus have drawn some very interesting parallels to the world of professional chefs (see Harvard Business Review article by Ron Friedman). In a restaurant kitchen there is a way of working that has evolved to get the best quality and most predictable outcomes and it’s called “Mise en place”. This is French term for “everything in its place” where the focus is on having all your ingredients measured, cut, peeled, sliced, grated, etc. before you start cooking. Pans are prepared. Mixing bowls, tools and equipment set out. It is a technique chefs use to assemble meals quickly and effortlessly.
Practising ‘mise en place‘ has several benefits:
- Any missing ingredients can be spotted before it’s too late for a quick trip to the store or your neighbour next door.
- Special preparation for ingredients — such as toasting nuts, letting certain ingredients come to room temperature, etc. — can be handled BEFORE cooking rather than in the midst of another preparation step when time delays may affect food quality.
- There is time to clean the mixing area as you go along rather than face a counter full of mixing equipment when you’re done.
- You can group ingredients or place them in the order used to assure all recipe steps are included.
- It makes complicated recipes more fun to prepare when you’re no longer doing a juggling act, trying to complete several tasks simultaneously.
In short ‘mise en place‘ is about contemplation, preparation and orderly execution. These very same factors are essential elements to completing the sprint ‘how?’ planning stage. This translates into a process where the agile team are collectively working to decompose a user story into a set of tasks that in aggregate deliver on the requirements across all business aspects. One common stumbling block to completing this exercise is the absence of a repeatable and consistent method for team’s to follow when attempting user story to task decomposition.
An alternative approach to estimating user story implementation effort is the ‘planning poker’ method. Personally I’ve yet to see this approach work on anything other than trivial story backlogs, as planning poker encourages ‘group think’ (bad), and a superficial view of the problem decomposition. In ‘mise en place‘ terms, I’ve found that agile teams playing planning poker never seem to get out of their chairs to check the larder for ingredients. Also planning poker is really a cut down comic book version of the old Wide Band Delphi technique, so if you want to follow this approach do it properly.
For the ‘how?’ planning stage to deliver reliable outcomes it is necessary for the team to decompose the user story into actionable work items or ‘tasks’. Below I have outlined seven tactics that I believe can be used as a checklist/template method to help with that exercise:
Tactic #1 – double check quality expectations, especially non functional quality expectations
Always double check the quality expectations for a user story, especially when it comes to non functional aspects such as security, performance, scalability and resilience etc. A friend recently related an episode where his business was asked by a marketing agency to build an ETL process for moving customer product review data out of an web analytics platform into a CRM product. Simply enough, until the marketing agency came back with feedback after the first sprint along the lines of “didn’t we mention that this is for Europe’s biggest supermarket chain, and the process needs to migrate 400 million records in less than a hour?!?”
Use the following question template to gain insight on non functional requirements: “do you care about xxxx, and if so, what are the constraints?”. Substitute ‘xxx’ with with the following qualitative aspects: ‘performance’, ‘throughput’, ‘data volumes’, ‘number of current users’, ‘scalability,’ ‘resilience’, ‘reliability’ etc.. Add the answers to the user story to ensure that all parties are aware of these emerging requirements. Addressing non functionality requirements will lead to the identification of new tasks. Continuing my earlier example, my friend had to build a test harness and test data set that would prove that the 400 million records in an hour expectation had been met. This ended up being a very significant task, taking more time to build than the core functionality.
Tactic #2 – practice assumptive planning
Assumptive planning is a technique used to put the viewer in a place where a goal has been achieved and they can reflect on what the end product represents and how it was achieved. For sprint planning purposes this is like asking the agile team to time travel forward to the end of the sprint, and imagine how – looking back – the user story has been successfully delivered. This technique is useful as it frees the team from worrying about existing baggage/constraints and starts to free their imagination on what is possible and how it can be achieved. It can help identify the primary components of the user story implementation.
Tactic #3 – orientate tasks around outputs not activities
A user story is a business orientated statement of aspirations/requirements. The primary goal of the agile team is to translate those aspirations into a practical reality where things are designed, built and tested to meet those expectations. For this to work the agile team has to focus the task break down around outputs not activities. A tell tale sign of inadequate task planning is where you see vague activities like: “design”, “coding”, “testing”. Coding what?
Modern software architectures involve multiple layers, and it is highly likely that a user story is going to impact many aspects of that model. A user story may require change in the web UI tier, business logic service changes and new database requirements. The tasks associated with implementing the user story have to specific to the output being created or amended. For example, “Add new web UI form to admin area to support widget config“, “Refactor widget service to support new retrieval use cases“, “Add new tables to DB schema to hold widget to user associations“.
Tactic #4 – think about discovery/prototyping
If the implementation plan for a user story envisages the use of technology that hasn’t been used before in anger, or an integration requirement with a new third party platform, then make sure that the task list includes some prototyping tasks that allow for a learning experience. Typically this is about building some stand-alone prototypes that can be used to validate knowledge and/or prove assumptions.
Tactic #5 – keep tasks small
Keep tasks small and discrete. This is a key factor in making a task list sensible and at a level where it is easy to apply time estimates. If a task can’t be estimated then keep decomposing it into smaller tasks until the unit of work is more clearly identifiable. My own view is that tasks should be set at half day level or less. In contrast teams should avoid detailing every itsy-bitsy change as a separate task. For example, if a user story requires database schema changes in a six places and each change takes 10 minutes then its not meaningful to break out each change as a separate task. It’s better to group them into one overall task of an hour.
Keeping task sizes to a half day or less is good for tracking sprint progress and also good for team morale. More things get done.
Tactic #6 – discuss how to prove quality
With an output view of the things to build or refactor there is another perspective to consider that may generate further tasks. For each output, how is quality going to be proved? This generally equates to a new testing task. Given the importance to agile methods of having rapidly executable regression tests, this also means considering the importance of building or extending automated test suites to validate output quality. It is not uncommon these days for teams working on multi tier applications for the effort associated with building test suites to well exceed the time to build the core functionality being tested. Tasks associated with proving quality should be annotated to define their own outputs, like: “build test rig and test data for performance testing new query methods on widget service”
Tactic #7 – addressing other stakeholder perspectives
It is vital these days to consider ‘cost of ownership’ and ‘cost of management’ questions when building new facilities. In an ideal world the product owner would have these other concerns included in the product background, yet this is rarely the case. To address this gap the agile team need to pose a set of special “design for <stakeholder>” questions, to ensure that the interests of other business functions are suitably addressed. This includes: QA, information security, Support and DevOps. For example:
- ‘Design for security’ perspective. How are information security model concerns being addressed in user story implementation?
- ‘Design for QA‘ perspective. Does the QA function have all the facilities required to black box test the user story outputs? Sometimes for services/API’s this means adding support for new functions that are there solely to support testing priorities.
- ‘Design for Support’ perspective. Do the outputs associated with the user story include a requirement for transaction trace-ability, instrumentation, service management , logging, data management/archiving, perhaps even a service management dashboard? If so, then the Service function will need these deliverables just as much as the core functionality. Make sure that your task list includes work to build all of these elements.
- ‘Design for DevOps‘ perspective. Will the user story implementation require new CI, build or deploy mechanisms? Again, review the task list to ensure that these aspects are addressed.
Planning is hard. User story to task decomposition is tough, but a failure to address this challenge is a common cause for why agile team’s fail to meet sprint objectives. So don’t skimp work on the sprint planning meetings, and make sure that the team perform their own ‘mise en place‘ when it comes to performing this duty well.