Using project briefs to develop the full potential of Agile teams

Using project briefs is about creating a lightweight process that can maximize the effectiveness of Agile teams.

Agile is all about quick iterations. Teams decide what work might have the most impact, execute on it quickly, observe the results, and readjust their direction to keep heading towards the goal along the most efficient path.

While speed is a huge part of Agile, teams can sometimes get lost in the flurry of delivery and turn into a feature factory. This can be especially true when pressure mounts to deliver quickly. The critical steps of weighting potential next user stories and forming a hypothesis, as well as observing and reflecting on the outcomes of work previously delivered, can get minimized or lost in the shuffle. This can result in teams spinning their wheels or delivering in the wrong direction or without the expected impact. Worse yet, it can be hard to pinpoint why the expected outcomes aren’t happening.

This post is about using project briefs to maintain a balanced Agile process that caters in equal parts to intentionality, speed and learning.

How are project briefs useful?

Very simply put, a project brief is a short, one- or two- page document that articulates why the project is being worked on, lists who is doing what, spells out the expected outcome, and lists the learnings gathered after the results have been observed.

Further down in this piece, We’ll talk about what a brief contains, but we want to start by explaining why we’ve found them useful.

Basically, project briefs help solve several common problems product teams face.

One common problem could be called analysis paralysis.

For example, some large organizations demand extensive business cases to justify a project before it can start. The time spent creating these business cases stifles innovation and slows the Agile team to a crawl.

Another common problem is the lack of checks and balances within the team. In some supposedly very nimble organizations, people just come up with random ideas and keep adding features to the product based on assumptions or one-off conversations with a customer.

A third common problem is the lack of big-picture learning, so that lessons learned on one project can be applied to others.

Project briefs address all those issues – and others.

For example, by merely listing a summary of the business case, the brief frees the team from getting bogged down in creating a long and intricate business case document.

By listing expected outcomes, measuring success and creating a feedback loop, project briefs create checks and balances that ensure thoughtful use of resources.

By spelling out why the team is working on a project, they improve team performance. People like to understand the impact their work has on the common good. We have found that the best way to motivate smart people to get something done the right way is to tell them why they are doing it and giving them a purpose.

And by creating big-picture learnings, we can over time improve the way we work and what we choose to work on. With a history of a project, we improve our understanding of the business. This helps teams avoid missing the forest for the trees.

What does a project brief look like?

The project brief document is an upfront planning document that is based on OODA loops (observe, orient, decide, act). Its purpose is to keep a project flowing smoothly.

The document lists steps in the development process, spells out why a project is being worked on, and includes follow-through to capture key learnings.

We keep it short (one or two pages) and base it on a lightweight template that people can fill in.

Writing the brief is usually the responsibility of the product manager or product owner, but team members can and do contribute.

There’s a sample project brief below, but first we want to present the template we use.

The template:

• Lists team members involved in the project.
• States the business case, providing a one- or two-paragraph justification for the project.
  • What context brought about the need for the project? Are there any hard data and strategy decisions that provide the foundation?
  • Why is this project the right response to the context? What result do we expect?
• Provides a set of measurable hypotheses.
  • How can the team translate its general idea about the expected impact into very specific verifiable statements, so it can clearly say that it was right or wrong at the end?
• Offers a measurement and analysis plan detailing how the team will gather the data needed to verify the hypothesis above.
• Outlines any expected interactions & impacts on other departments.
  • This could include a sales & marketing plan
• Outlines in the implementation notes how the project was carried out, including pointers to specs and notes on when and how the project was released.
  • This is important information for someone coming in later to analyze the project data.
• Summarizes results, including:
  • A brief overview of each measurable hypothesis
  • Learnings & next steps
  • What to do next, based on the outcome

Download our simple example case:

Summary

The fastest way to mid-term results is a short-term focus on learning. Without having a defined expectation of the outcomes, the product teams activities can feel and look like aimlessly running around in multiple directions. The expected outcomes by a feature or user story don’t always need to be meaningful business impacts like increased revenue - although that would be amazing! Taking an experimental approach, learning and formulating the next steps is also very valuable.

We think we have found the answer for how to keep the balance between staying agile and intentional while continuously learning. The answer is short and sweet project briefs. We encourage you to give them a try and let us know what you think.

- Ali Pourshahid, Ph.D., is the VP of Software Development at Klipfolio. He can be reached at @ali_pourshahid.

- Tomasz (Tomek) Ogrodzinski, is the Principal - Research & Analytics at Klipfolio. He can be contacted on LinkedIn or at togrodzinski@klipfolio.com