The Agile Project Kick-off Kit gives you the tools, templates and tips you need to get your project off to a successful start.
"Brilliantly done - very impressive."
— Jimmy Ling, Agile Delivery Lead, NAB
Your product discovery workshop will help you discover:
The guide is for anyone planning an Agile project discovery workshop.
You may be:
This guide includes:
Presenting the Product Vision at the discovery workshop is a chance to inspire the team by depicting the better future you’ll be building. The vision brings the team together, giving them both destination and motivation.
45 minutes
The Product Owner can present the vision solo or as a tag team, ideally with the chief executive or another senior leader. This shows shows that the powers-that-be are behind the project. It’s also a chance to link the project to the organisation's strategic priorities.
The Product Vision explains why you’re building the product. It paints a picture of the way the product will improve the lives of your customers, and how this benefits your organisation.
The presentation:
Roman Pichler has put together 8 tips for creating compelling product visions.
Once your presentation is over, it’s a chance for you to answer any questions the team have.
The next two activities let the team flesh out the vision. Both the Press Release and the Elevator Pitch help the team better understand the benefits the product will bring. You can run either or both of these exercises.
The Press Release goes into more detail and focuses on benefits for both the customer and the company. The Elevator Pitch sums up in a single statement your product’s unique selling point in the marketplace.
Producing a Press Release is a fun way to get a shared view of your project’s purpose by touting the benefits it’ll bring.
45 minutes
Imagine your project is complete and you’re writing a press release to plug your awesome new product.
The Press Release activity:
We’ve also tried the Product Box activity but we found the Press Release is better for getting everyone involved; you don’t need much in the way of artistic talent.
The Press Release template we use follows Ian McAllister’s approach at Amazon.
Press Release template with instructions — PDF
Blank Press Release template — PDF
Set the scene. You might say something like, “Imagine you’re in a cafe. You’ve got your coffee and cake and you’re reading the paper. Your product is live, you’ve sent out a press release and the newspaper has picked it up. What will the article say?”.
Explain that the Press Release is meant to get the reader excited. It celebrates the success of the project and highlights the way it’ll make the world a better place. Be creative. You’re after a story that people would want to read.
Don’t skip over the scene-setting — it helps people get the imagination working.
If people get stuck, remind them that you’re not looking for the perfect press release; the conversation is as important as the final product. Sometimes it’s easiest to start with the Problem and its Solution. The facilitator can give people a nudge by offering another perspective.
Check out this example press release.
Give each group a couple of minutes to present their team’s release to the workshop.
Discuss what you’ve learned. Ask the team if they noticed any:
Take a photo of each release. Some of our clients have liked the end result so much that they’ve circulated it internally. In this case we tend to transcribe and spruce-up the press release.
If you have a number of releases and no standout candidate, you can distil them into a single vision through the Elevator Pitch. This activity also helps the team understand how the product will be positioned in the marketplace.
Writing an Elevator Pitch at your discovery workshop helps distil the team’s shared vision for your product, and the edge it will have against its competitors.
30 minutes
The Elevator Pitch gives you something that helps the team position the product in the market and promote it to stakeholders.
This is based on the template from Geoffrey Moore’s book Crossing the Chasm.
For [target customers]
Who are dissatisfied with [the current market alternative]
Our product is a [new product category]
That provides [the product’s key problem-solving capability].
Unlike [the product alternative],
Our product [describe what the product does, its key features].
Imagine you’ve invented sliced bread. Here’s how you might fill in the template:
For toast aficionados
Who are dissatisfied with bread you need to cut yourself
Our product is a pre-sliced loaf
That provides uniform slices of bread straight from the packet.
Unlike uncut bread,
Our product saves time and provides a consistent toasting experience.
This activity keeps you busy as a facilitator. You need to capture suggestions as the team call them out and then identify the consensus view based on the discussions.
People can get hung up on finding the perfect wording. This conversation is valuable but you need to guard against running over time. If people fixate on individual words and phrases, listen for the essence of their ideas and offer alternative phrasings.
You might do a couple of drafts before you get something you’re all happy with.
Next up, you take a break from thinking about what you want from the product, and start thinking about what you want from the project.
Success Sliders are a simple way for the team to agree on the project’s priorities. They help you kick off your project with a common understanding of what success looks like.
20 minutes
Success Sliders make explicit the fact that your project has finite resources and give you a transparent way to make the necessary trade-offs. Increase the scope, for example, and your project will take longer or you’ll need a bigger budget to hire more people to complete the work in the same time.
Rob Thomsett introduced the idea of project Success Sliders in his book Radical Project Management.
On a poster or whiteboard, draw a grid of 6 rows by 5 columns.
Label the 6 rows with your success factors. In the example below we’ve chosen common factors for software development projects.
Number the columns 1–5.
Place post-it notes in column 3 of each row.
Tell the team to work together to decide the priority of each success factor. The more important the factor the higher of the number of the column it sits under. (You can have more than one post-it in each column.)
In doing this, you’re giving each factor a numerical value. But here’s the catch: the total value of all factors must equal 18.
This means that if you raise the value of one factor you’ll have to lower the value of another. The team has to agree how to balance the values for each factor to stay within the magic number.
Putting a limit on the total value reflects the real-world constraints that all projects face. It lets you kick off your project with agreed priorities.
A completed Success Sliders exercise, with the total value for all the success factors adding up to 18.
If you’ve got access to a big screen, you can run the activity online using a tool developed by Mountain Goat Software.
Online Project Success Sliders tool
Now you’ve agreed on the priority of your success metrics you can decide who your priority customers are, and how your product will improve their lives.
Pragmatic Personas let you quickly and collaboratively turn existing customer insights into memorable characters that the team can design the product for.
45 minutes
Pragmatic Personas convert generic users into characters whose traits you know and whose needs you understand. They’re a fun way of keeping the customer top of mind during the discovery workshop.
This template is based on Jeff Patton’s approach.
Pragmatic personas template PDF
Blank pragmatic personas template — PDF
These personas are pragmatic because they’re quick, collaborative, use your existing customer insights and produce something the team can easily refer to as they work. You can turn dense customer research data into something accessible and actionable. If you don’t have detailed research, you can use the collected wisdom of the group to make educated assumptions.
Pass around the template or draw it on the whiteboard. Describe what’s needed in each section.
Brainstorm your key customer types and pick the top three. While “everyone” could conceivably be a customer, if you try to build a product for everyone, you won’t satisfy anyone.
You can print out the blank pragmatic personas template and get them to fill that in or give them a blank sheet and get them to draw up the template from scratch.
If you’re doing multiple personas, split into groups and tackle one persona each. Once they’re done, give each group a couple of minutes to present their persona to the workshop.
Then capture the personas and make them visible so the team and stakeholders can refer to them later.
Alliteration helps makes the names memorable. For example, if you’re developing sliced bread, you might target two personas: Tony Toastmaker and Sally the Sandwich Addict.
You might find people start out anxious about their artistic talent but once they get going they tend to have fun. And the act of imagining what a persona looks like helps bring it to life.
Keep the Context section down to a few bullet points. You can put more detail into the About section.
Only list characteristics of your persona that are relevant to the design of your product.
Watch out if you start listing features here. You run the risk of going into too much detail.
Check out this example persona.
As a group, rank the personas in order of importance. Consider who your most valuable customers are and who will get most benefit from the product.
This prioritisation is important because you’ll focus your development efforts on the top persona. To make this easier, give each persona a different coloured sticky dot. You’ll use these to tag your user stories later in the day.
Now you know who you’re building the product for, you can start building up a more detailed view of what you’re going to build. You’re ready for User Story Mapping.
User Story Mapping is a way of brainstorming all the work you’re going to need to do to build the product, then breaking it down into a structure that will make your development simpler and more manageable.
90 minutes
User Story Mapping gives your discovery workshop two types of map. Firstly, the exercise itself guides you to the point that you can start writing user stories — short descriptions of what your customer will do when using your product. Secondly, the end result is a visual chart showing the structure of your stories. These stories and this structure will guide your development work.
You can learn more in Jeff Patton’s book User Story Mapping: Discover the Whole Story, Build the Right Product.
An outline of the structure of a user story map
Describe the purpose of User Story Mapping and outline the five-step process. Because it’s complicated, people might not fully grasp what’s involved initially. That’s fine, it’ll become clearer as you go.
This works best as a silent brainstorm. Working alone, each participant writes down on a post-it note every step the user will take through the product from start to finish, one step per post-it. Encourage the team to think of these as actions not features by writing them with a verb at the beginning.
This phase is about breadth not depth. Tell people to be creative and try to cover every action possible. Discourage adding much detail about individual steps.
Stick each post-it up on the wall in the order the users will do the tasks. This gives your story map a chronological structure.
Make sure the post-its are in a straight horizontal line. Place duplicates beside each other on the line (not above or below) to leave space for the next steps.
For example, the user tasks for making a piece of toast might be:
As a team, look for logical groupings within your line of user tasks, collecting together all the tasks that contribute to the user achieving a wider goal. These groups are your “epics”.
Write these epic labels on wider post-its and place them above the user tasks that the epic covers. Make sure the labels will be meaningful later. Keep them brief (3-5 words should do). Again, it helps if you start with a verb.
You might group user tasks for making toast into epics like this:
| Epics | Get loaf | Get single slice to toast | Store remainder | ||||
| User tasks | Buy loaf | Carry loaf home | Open bread bag | Get single slice | Place slice in toaster | Reseal bread bag | Place in freezer |
| Epics | User tasks | |||
| Get loaf |
|
|||
| Get single slice to toast |
|
|||
| Store remainder |
|
This is another silent brainstorm session.
Ask the team to think about everything that needs to be in place in your product to let the user achieve the goal of the epic. Each of these smaller units becomes the name or “stub” of a user story. Again, it’s important to write them so they’ll make sense later.
Thinking of the sliced bread example, here’s the work your team would have to do for our hungry customers to achieve these goals:
As a team, post them up under the user tasks, and the wider epic, that they apply to. If there are duplicates, choose the best and stick that up.
To make sure your map is comprehensive, get people to walk down the line looking for gaps.
Now you’re ready to start prioritising the user stories on your map.
| Epics | Get loaf | Get single slice to toast | Store remainder | ||||
| User tasks | Buy loaf | Carry loaf home | Open bread bag | Get single slice | Place slice in toaster | Reseal bread bag | Place in freezer |
| User stories | Bake loaf | Cool loaf | Slice loaf | Bag sliced loaf | |||
| Epics | User tasks | User stories | ||||
| Get loaf |
|
|
||||
| Get single slice to toast |
|
|
||||
| Store remainder |
|
|
Prioritising your user stories lets you identify the business value of each story, do the most valuable work first, deliver quickly in order to get feedback, and then review the remaining work based on what you’ve learned.
30 minutes
Because this is an Agile discovery workshop, you’re not aiming to define all requirements, just discover the least you can do to achieve your project vision.
So now it’s time to decide which of the stories deliver the most value, most quickly.
Next, you’ll find the smallest collection of these stories that together will produce something your customers will find useful. What is the Minimum Viable Product (MVP) that will be valuable, and will let you gather valuable feedback from your customers?
You’ll then be ready to write the user stories for this MVP. These stories will guide the development of the first iteration of your product.
You’ve already ranked your personas by priority and given each of them different coloured dots. Decide which stories mainly benefit one persona and stick that persona’s dot on those stories. Straight away you can see which stories offer the most to your most valued persona.
Next we decide which stories we Must, Could, Should and Won’t do (MoSCoW for short).
Those stories that mainly offer value to your top persona tend to be high priority, though they’re not invariably Musts.
An outline of a user story map after the stories have been prioritised
Stick three rows of tape across the wall (the green dashes above). Leave room between the strips. You’ll be grouping user story post-its between these lines.
Now move all the Musts above the top line of tape. While you’re at it, move all the other stories below the line, grouping them into Shoulds, Coulds and Won’ts. Arrange the user stories under the epic they help achieve.
You’ve now got your stories ranked in priority from top to bottom. At the top, the collection of Musts is your Minimum Viable Product.
Get the team to walk along the map and make sure these Musts are all and only the stories needed to produce a cohesive, standalone product that lets customers complete enough of their goals that they’ll adopt your offering.
Be ruthless. The critical question is whether the customer can still achieve their goal if you don’t do a particular story.
Record the epics and all the user stories (you don’t need the user tasks). The non-MVP stories go in the backlog as a stub.
You now have a shared understanding of what’s important. Keep in mind that this understanding may change as you learn more by getting feedback on the MVP.
There are other prioritisation techniques you can use, but this one is quick enough to complete in a one-day discovery workshop.
Next up is writing user stories. You’ll only create stories for the Musts. This minimises the work you have to do before you start developing.
Get the hang of writing user stories by starting with the must-do stories that make up our Minimum Viable Product.
90 minutes
Because they describe a feature of the product from the customer’s point of view, user stories are a great way of expressing the benefits of a project and providing a conversation centre until they have been completed.
There's a simple formula for writing user stories so they focus on the customer benefit.
As an [actor] I want [action] so that [achievement].
The actor is often a type of user (and may be one of your personas). The action is what they want to do using your product. The achievement is why they want to do it — the benefit they’ll get.
So a user story for our movie theatre booking example might be:
As moviegoer, I want to choose the seats I book so that I get the best available view of the screen.
This statement of the customer benefit is the core of the user story. You can add more detail throughout the iteration as you discuss the story with the team. Learn more about how you add detail and write effective user stories in Scrum.
Writing the user stories for the MVP takes your discovery workshop to the point that you can start developing your product. So now you know what you’ll be working on, you can decide how you’ll work.
Create a tight team with a shared commitment by jointly deciding how you’re going to work together.
20 minutes
It’s nice to cap off your discovery workshop with an exercise that bonds the team together and builds a shared understanding and commitment. You’re more likely to get a great team when the team itself sets the ground rules.
You can include:
You don’t want to duplicate things like:
As a rule of thumb, if your charter is too big to remember, it’s probably too big.
You don’t need the stakeholders who have been part of the rest of the Kick-off, just the team — including the Product Owner — and the facilitator.
As facilitator, you should avoid making suggestions. Instead, try to ask open questions. These might be things like:
Capture each point, perhaps on a flipchart or whiteboard. Make sure each point clearly describes what was intended and is understood by everyone. When the points stop coming, review them all to make sure they’re relevant and there are no big gaps.
It’s best to have both a physical and an electronic copy. Post the paper version beside the project board and put a photo or transcript in your digital tool.
The physical copy keeps the Charter in front of the team every day, while the digital copy is available for people working off-site and as a back-up.
As well as a Team Charter for each project, at Boost we have an overall Team Charter covering how we work as a company.
You now know why you’re building the product, who you’re building it for and how your team is going to work together.
You understand what you need to prioritise in order to deliver a working solution you can test and tweak until your customers can’t get by without it.
Ready! Set! Deliver!
Get more in-depth guidance on the activities in the discovery workshop.
If you’re based in New Zealand, Boost can plan and facilitate your discovery workshop for you. Contact us to learn more. It’s a great way to get clear what you want to achieve, how long this will take and how much it will cost.
Learn how the project discovery experts can take the hassle out of building your business case and getting your project up and running.
The Agile Project Kick-off Kit collects all the tools, templates and tips you need for a successful discovery workshop into one handy 39-page PDF.
"Brilliantly done – very impressive."
— Jimmy Ling, Agile Delivery Lead, NAB
Make a bigger impact tomorrow
