I’ve picked again recently on the theme of Agile planning in this blog and thought I would continue with a few brief thoughts about the context for planning.  I talked earlier in this series (way back in January of 2014) about portfolio planning and product roadmaps that set plans for individual sprints and releases into a larger context of the corporate vision for product development.  Here I want to talk about a different angle for examining the context of planning.

Over the past couple of months we have begun thinking about ‘jobs to be done’ (from Clayton Christensen – see more here) rather than user stories or epics as the way we conceptualize what to work on.  The key questions we ask in this approach are what are our customers trying to accomplish and how does this fuel the design and development of our product.  Why do prospects ask about a specific report, or why do clients want access to certain types of data?  What is the business problem they are seeking to solve and what can we do to make it easier for them to get the resolution they need?  The ‘job to be done’ concept in some ways parallels the ‘epic’ idea in that it often involves several components of a broader solution.

Discussing the job to be done with at least the lead developer and designer has a number of advantages.  First of all it gives them a wider context for understanding why we developing our product; the more deeply they can grasp the business needs of our end users the more they can utilize this insight in developing the architecture and features of our product.  Knowing the business goal also provides added motivation for the development team; when they know that they are building something that meets a real client need this can be more energizing than simply coding a new feature because the product manager said we want it.

While providing context and motivation for the team through discussing the job to be done is valuable, taking this approach has the added benefit of leaving the ‘how’ of product creation in the hands of the designer and developer.  Talking about the jobs our clients want to accomplish without specifying how to solve those problems allows the designer and developer the freedom to think about the technical approach that best accomplishes this job.

We are relatively new in seeking to utilize the jobs to be done framework to set the context for our product planning, but so far it has been helpful in providing a wider vision for the development team that sets our sprint plans in context.  We still need to break the solution into smaller pieces that can be worked on in individual sprints and even on specific days within the sprint.  The larger job to be done might break down into multiple user stories that each address one step in the problem solving process; then these user stories might be further articulated as specific tasks for the team to work on.

In our scrum team our typical tasks are estimated at between half a day and two days of effort.  I must admit that in thinking and writing about Kanban and XP lately I’ve been wondering if we should try for shorter ‘stories’ that can all be completed in less than one day.  This balance between wanting to give adequate context for the work we do (whether you call it a user epic or a job to be done) on the one hand and wanting clearly articulated tasks that can be estimated and committed to for a specific sprint on the other hand is something I continue wrestling with.  The ‘jobs to be done’ framework appeals to my big picture impulses but it doesn’t fully resolve this struggle because in truth it’s not that simple.