Iterative Sprint Planning

I’m encountering a recurring theme in my agile coaching. Some organisations have a sharp divide between their business and IT functions. This always spins off a twin-track coaching path for me: on the one path let’s try and address the fundamental root cause of the dysfunction/divide and on the other path what can we do to ameliorate and get around the problem in the short term?

So far my experience is that most of the symptoms of this issue are revealed via the Product Owner role. Sometimes business folks just don’t understand the basics of either software engineering or software economics. It’s just a simple inevitability of the organisation and experiences/skills their career paths have taken them on. So they can be experts of the business domain, but appreciate none of the pain and realities of software development. That is not a trivial problem to solve and will likely take a lot of effort and time. So in the meantime, what should we do to minimise the impact? Well, for sure, this is going to depend on all sorts of factors surrounding what exactly the problems are being created by having Product Owners with no software experience.

I’ll describe what I have found works quite well at one particular client in regard of one slice of this overall challenge: Sprint Planning.

The difficulty faced by the agile teams was that the allotted time Sprint Planning was always reached before any kind of commitment to the content of the Sprint was close. On closer examination, there were (as so often is the case) a number of contributing causes for this and all need attention. As well as the common issue of developers being uncomfortable with the relative sizing of backlog items without knowing almost every line of code impacted (they may have got bitten in the past), the thing that seemed most acute was the compounding problem of unclear requirement. With the lack of an empowered and embedded full-time Product Owner, it was perhaps inevitable that even well-formed User Stories were insufficient in getting a shared understanding of the requirement to the agile team(s). In this circumstance, we have used a Business Analyst as a proxy Product Owner with regard to backlog generation.

Scrum and similar methods describe the Sprint Planning event in some detail. They suggest a planning meeting of around four hours per two-week Sprint. There is also a recommended ≤10% allowance in the Scrum Guide for backlog grooming and refactoring by the whole team. By converting that ≤10% grooming into more structured events, we are finding it much easier to contain the planning to the suggested time boxes. The structuring consists of three iterative parts to Sprint Planning:

  • GET-AHEAD sessions. The proxy Product Owner meets regularly with business (and other stakeholders) to discuss upcoming requirements a Sprint or two ahead of when the requirement needs to be delivered as a backlog item/ User Story. By starting these meetings ahead of the Sprint execution, it gives the diverse stakeholder community the opportunity to address issues and questions raised concerning the requirement. Typically, this was left until the Sprint Planning meeting previously, giving no time for issues to be analysed and answers to be gathered. This not only gummed up the Sprint Planning, it also blocked the subsequent Sprint execution. The agile team need not be involved in the GET-AHEAD sessions (it isn’t an effective use of their time) – this helps reduce the overall amount of time that the team spends in planning sessions.
  • CONFIRM sessions. Once the proxy Product Owner has established the requirement to a comfortable degree, the backlog refactoring would continue by discussing the requirements with the team. By this stage the requirement is largely understood by the proxy Product Owner so whilst business stakeholder attendance could be useful, it wouldn’t be mandatory. Discussions in the CONFIRM session are generally more technical and where the Product Owner is not of a software background, this is of limited interest to them and not a great use of their time. Whilst the proxy Product Owner would be able to answer most questions that the team would have, sometimes more questions may be raised and these are taken back to the next GET AHEAD session (hence the process is iterative). Typically relative sizing of the stories (through planning poker) starts in CONFIRM sessions but not task decomposition.
  • COMMIT sessions i.e. the Iteration Planning Meeting itself. Once the major issues have all been resolved in good time, the team can confirm the story content and sizes, do task decomposition and estimation, then commit to the delivering the work in the impending Sprint.

By following this process in an iterative way (just enough planning in just the right amount of detail), we have been able to get much more meaningful Sprint Plans produced just in time. There is still some way to go to get this working in an optimum way, but we have reduced one major impediment and can now move onto tackle others…


4 Comments
  1. Russ Lewis | September 30, 2012 at 6:24 pm Reply

    avatar

    I once mentioned “proxy Product Owners” to an audience of senior managers, who were being groomed for, and informed about, the PO role.

    Whilst I was thinking in terms of “supporting” the product owner, to my horror they immediately decided they would replace the PO with Proxy POs, thereby relieving themselves of any of the responsibilities of being a PO.

    Mind-you, it also revealed a lot about their ideas of management!

  2. Ed Seidewitz | September 28, 2012 at 8:55 am Reply

    avatar

    Gee, the role of “proxy Product Owner” seems to be almost exactly what I would call a “true Architect” — especially if I understand correctly the implication that the proxy Product Owner should be a Business Analyst with some technical understanding of software development.

    To my mind, having an Architect (as I would call the role) who can talk credibly with both business and software people (just like a real building architect can talk both creatively with the client and technically with engineers) is critical for any non-trival software development effort, whether it is done agilely or not — which is, I think, also reflected in your experience. Unfortunately, this is sometimes not understood in the context of agile development, especially when there is a misapprehension of a “Software Architect” as just being a “senior software designer with an inflated title” (admittedly a misapprehension that has been reenforced by some of the people wrongly given the title). Nevertheless, there has been increasing discussion in the agile community lately of the importance of architecture and how it can fit properly into agile development.

    My take on this post is that it can be considered a contribition in that context, leading to what could be a nice synthesis captured in the idea of “Architect as proxy Product Owner”.

  3. Mike Carew | September 26, 2012 at 3:29 am Reply

    avatar

    The confirm session in particular would benefit from a well understood and agreed definition of READY. This has been a helpful checklist in my experience. People would know what shape a story should have if they expect that it meets INVEST and is therefore ready to be moved into a COMMIT sessions. So I recommend that the team and the PO work to define READY and then apply it during the CONFIRM session. This helps both parties understand what they are trying to get out of the session.

    Mike

    • Nick Clare | September 26, 2012 at 5:19 pm Reply

      avatar

      Yes, using a common definition of READY is often an appropriate way to ensure that agile devlopment teams don’t get “stuck” during execution of a Sprint, especially if READY includes the INVEST crtiteria. One thing to be careful of perhaps is that the READY definition doesn’t state or infer a particular solution that would unnecessarily constrain innovation by the agile team.