There’s no mention of Project Initiation Documents (PID) in Scrum so why as a Product Owner would you use one? After all, Scrum promotes all interested parties being present when planning takes place. In reality, even the most Agile teams struggle getting everyone into the planning session all of the time. Whilst (at minimum) all members of the feature team plus Product Owner and ScrumMaster should be present I’ve always found it a challenge getting the higher level stakeholders to the meeting. Sales directors, CEO’s, CTO’s all have various calls on their times and are usually unavailable.

What Scrum says should Happen
This is why we have a Product Owner right? The Product Owner is the business representative in the team it’s the Product Owner’s responsibility to ensure they are engaging with the key stakeholders and and made the correct priorty calls in the best interest of the product. A key part of the Product Owner role is ensuring this vision is communicated back to the stakeholders.

Communicating the Product Owner’s Vision
In the past it’s not been uncommon for stakeholders to return to the office after a story workshop and realise they misunderstood the Product Owner’s vision. The team have wasted valuable time running a story workshop and starting the first sprint when it seems the senior stakeholders are not on the same page.

Yes, we’ve tried to get these stakeholders into the same room and have a high level discussion around the proposed project prior to starting the story workshop. However, when it is difficult to get these people into the same room (especially when it’s very senior stakeholders such as):

  • Managing Director/CEO
  • Sales Director
  • Product Director
  • CTO

The Product Owner has a tough (almost impossible job) to get these guys on the same page. Even when we have managed it we’ve only been able to get them together for 10 minutes or so, far less than is needed for a topic as important as this.

Communicating the vision through an Agile PID
To address this problem we introduced Project Initiation Documents into our Scrum process. Surprised? Well, it made sense, after all Agile is largely common sense and we felt this document would really add value and (hopefully) prevent misunderstandings. The main purpose of the document was to give stakeholders and (once signed off) the team a high-level insight into the project. The document would promote discussion from the senior stakeholders and help flush out any assumptions. The PID had a few very simple rules:

  • The PID is:
  • Authored by the Product Owner.
  • No more than 3 pages (A4) long
  • Approved by all stakeholders before the story workshop can take place
  • Business focused and provides:
    • Business Case
    • High level overview of the features,
    • ROI strategy through releases
    • Risks
    • Assumptions
    • Potential Blockers

The Results Are In
We found Scrum with PID’s works and it actually works really well. The Product Owners found it wasn’t till they started writing the document that they really started thinking about their decisions. It’s a reflective process that before the PID they didn’t do enough of, by writing the PID they were constantly re-assessing their decisions and anticipating potential criticisms. The senior stakeholders liked it as they could read the document when they could give it their full attention it allowed them time to digest it, collect their thoughts in their own time prior to responding to all via email.

The document template forced Product Owners to tie their release strategy directly to ROI. This helped lessen waste by ensuring the proposed features had clear value. The document created lots of interest and generated the sort of conversation that was not present before. The team liked it as they had a well thought out product vision before the project’s story workshop had begun knowing the business case had been signed off by the senior stakeholders