Meeting paralysis vs. Just In Time planning

I enjoy attending meetings just as much as the next person (cough). There’s nothing like spending a day in meetings going over your sprint demo, retrospective and planning; followed by a technical/architecture design meeting to outline the approach for all stories in the upcoming sprint. Even with a double espresso, no cell phones and closed laptops, discussing the all nuances (tests, complexity, implementation details) required to commit and deliver a sprints worth of stories can be a daunting exercise. Just like kids in kindergarten, adults also fall victim to what I call “meeting ADD”.

Studies by Dianne Dukette and David Cornish (2009) have shown that our attention span tops out at about 15-20 minutes.  So it’s no secret that during marathon sprint planning or backlog grooming sessions, team members are prone lose focus on details that may come back later in the form of waste:

• scope creep
• misunderstood implementations
• incomplete functionality
• unnecessary work
• blocked stories that require revision during the sprint.

Time and effort may also go to waste as market influences, customer needs or escalations may trump previously planned sprint backlog stories.   Even-though two (2) week iterations may seem short, the longer stories/requirements sit on the shelf the more out of sync they become with the most recent user feedback or lessons learned.

Tell me what I need to know when I need to know it

I’ve found that leveraging Just In Time (JIT) planning helps to address waste and “meeting ADD”, as the team only meets to plan stories as Work In Process (WIP) limits allow.  For example, one of my former teams would stack groomed stories in the “Ready” column on our Kanban board (see Table 1 for example).  Then as capacity became available per WIP limit, we would plan stories and pull them into the “In development” column accordingly.  Story planning would be time boxed so that if we could not discuss, critique and commit to a story in 6-7 minutes it was probably too big and needed to be sliced or revisited after open issues were resolved.  This method prevented us from investing too heavily in stories at the beginning of the sprint that could be affected by latest feedback or changes in priority by the business during the iteration.   JIT planning also cut down time during weekly backlog grooming as we would only discuss enough stories to maintain the WIP limits of “Ready” column  (e.g. WIP = 10).  However, this approach did come at some cost. It required the Product Owner (PO) and development team to be closely aligned and highly available as feedback loops were shorter and impromptu planning sessions could be scheduled throughout the day.

Table 1

More is less?

Some may argue that JIT planning results in more meetings and potential disruptions during the sprint. Yes and no in my opinion. Yes in the sense that the number of planning meetings (or huddle as we’d call it), would be based on the number of stories pulled into the sprint.   On the other hand, it’s not as disruptive as one may think since only the development pair (e.g. Dev and QA) working the story and team technical lead would be involved rather than the entire team as with traditional sprint planning.  Moreover, since all team members are able to contribute their feedback during weekly backlog grooming JIT can make for an efficient use of the teams’ administrative time during the sprint.

Get Lean

Truth is most of us don’t like meetings but we need them to collaborate and get work done especially when dealing with knowledge work.  In my experience, teams can contribute more value through time-boxed, JIT planning as participants are more focused and engaged with the problem domain.  From a Lean perspective it also certainly addresses wasteful activities during development sprints.