The Big Picture Through Agile Inception Planning

When I was a kid, our family would go for drives out of the city to the countryside. These were more often a prison sentence for me in the crowded backseat with my two sisters. The only consolation was sitting next to a window but being the youngest, well, you can imagine I had the middle seat a lot. If there was a specific destination I was not aware of it until we got there. I was not happy sitting in the middle, the seat was hard as a rock and my sisters pointing out to me that they had the windows. It was sometimes miserable. So when the car got to a special place like the lake, I was already determined not to enjoy myself or at least, I took a while to lose the attitude. But I wonder what would have happened if in the beginning, my parents told me we were going to the lake for a picnic?

When the business starts a project, the project too can be either a prison sentence or an exciting adventure. While there’s no guarantee that everyone will be happy, there are steps the Agile Project Manager can take to help bring everyone on board, answer their questions, and give them an opportunity to participate and contribute toward a successful project. Giving the project team a complete picture of the business reasons for the project is good for business. To make the project goals be meaningful and effective in motivating the project team, they must be tied to larger business ambitions.  Team members who don’t understand the role they play in the business’s success are more likely to become disenchanted and look upon the project as a prison sentence. If however, the team members understand the business goals and how the project will help achieve them, they are more likely to be engaged and equipped to make better trade-off decisions when the project doesn’t go as planned.

An inception workshop is an ideal event that can help give everyone the big picture. The workshop gets the project team members thinking and can set the groundwork for them to make good decisions throughout the project.

Setup the Big Picture Workshop

An inception workshop can be thought of as a two part event. The first part is understanding the ‘why’ of the project from a business and customer perspective. The second part of the inception workshop will deal more with the planning aspects. Setting up understanding the Big Picture happens in the first half of the workshop.

There are several questions that everyone on the team will need to be able to answer at the beginning of the project to give them a better, more complete big picture. These questions are:

  • Why are we here?
  • What will we do?
  • What won’t we do?
  • What trade-offs will we have?
  • Who are our customers/users?
  • Who are our stakeholders?

The inception workshop attempts to get the project team to answer these questions without intimidation. The project team’s participation is essential. To maximize that participation requires openness, trust, respect, and courage to speak one’s thoughts out loud and to listen while others speak.

The inception workshop brings the project team into a large room where people can easily move about. They do not need to bring laptops, pens, paper, or books; they only need to be physically there. The facilitators bring tons of sticky notes, sharpies, flip charts, lots of wall space, phones to speak with customers or stakeholders, projectors, and strong time-boxing skills.

Why are we here

When the project team understands why they are working on the project, it can help make teams do the following things better:

  • making informed decisions
  • making trade-offs
  • being innovative

Getting the CEO or other business officers to describe why the business wants the project and what they hope to achieve, it helps focus the project. If for example the intent is to increase the number of people buying the product, it’s useful to know why they’re not buying it now. Depending on your business, the inception workshop facilitators bring in the CEO, head of Marketing, Sales, HR, Product, Development, and Support to discuss their business goals and outcomes the project will bring them.

When the team understands the intent of the project, they can make decisions based on that intent. To increase the number of buyers might require that customer  testimonials be made more prominent on the home page. If the user story comes up to add additional ad space, the team can decide that this story doesn’t immediately contribute to increasing the number of paying customers and prioritize it lower. Without knowing the intent, they probably would not make good decisions on priorities.

What will we do

During the inception planning workshop, the project team prioritizes business goals and objectives. Creating the elevator pitch is a lean way to get everyone sharply focused on the business intent and be very clear on what’s important.

Source: Dave Gray, Sunni Brown, and James Macanufo. “Gamestorming”. O’Reilly Media.

An elevator pitch is a description of the problem you’re solving, who you’ll solve it for, and the one key benefit that distinguishes it from other ideas. The project team collaboratively defines this pitch during the inception planning workshop. The product manager and Scrummaster/Agile Project Manager, get the group to answer these questions:

  • Who is the target customer?
  • What is the customer need?
  • What is the product name?
  • What is its market category?
  • What is its key benefit?
  • Who or what is the competition?
  • What is the product’s unique differentiator?

The full group starts by brainstorming ideas on sticky notes for each of the categories. There’s no discussion at first but everyone shares their ideas freely and largely silently. Use a large wall or whiteboard for the project team to stick their ideas for each category.

Once the ideas are up, break into smaller groups of 4-5 to develop an elevator pitch sentence. This is complete when the group reaches consensus. Each blank in the sentence contains at most one idea.

The last step is to finalize the pitch from the group inputs. Although important, it’s not critical to finalize this now, especially if there’s a large number of groups. The important part is the group as a whole have decided what the pitch consists of. The product owner can create the finalized version off-line if necessary.

What won’t we do?

When thinking about the project, we usually think in terms of the future product and new product features. We usually don’t think about what the project won’t do. Listing what features or capabilities the project will not do sends a crystal clear message to customers and stakeholders alike. What the “not in scope” list does is help define and manage expectations in an open way. The “not in scope” list can be the catalyst of conversations for future projects.

This is best achieved if the group uses a prioritization tool such as the MoSCoW prioritization method (Must have, Should have, Could have, and Won’t have). The group is asked to identify the features and capabilities the project could do and place these into one of the four columns. The elevator pitch would have identified the benefits and potential benefits of the product. The product manager will have a list of high-level feature work from the roadmap for the project. The project team spends 10-15 minutes sorting through the items silently or creating their own ideas of what should or shouldn’t be done, placing them into one of the four columns. What results is an MVP from the “Must have” column. The “Should have” column items can be considered for inclusion in the MVP but probably require more information before a decision can be made. The items in the “Could have” and “Won’t have” columns are considered out of scope for now. All of this may change over the course of the inception workshop but initial focus is placed on the “Must haves”.

What trade-offs will we have?

Trade-offs at the project level can become strong influences on how the project team approaches their work. It places priorities on those things that matter and de-emphasizes those things that matter less.

Get the project team to first decide what the sliders are. The example sliders above are probably the most used but the team may have others. The group then silently spends 5 minutes placing sticky notes on the sliders where they feel the trade-off is. “On” means most important and less negotiable while “Off” means less important but more negotiable. The consensus opinion will drive the results. After all the sliders are annotated, there is a discussion of the meaning of each slider selection for 10-15 minutes.

Who are our customers/users?

Understanding who your customers are means more than just having a customer’s name. It’s about understanding their motivations, desires, and pain points. Creating an Empathy Map is a quick and easy way to build a persona and get “inside your customer’s head.”

The product manager starts by conducting customer interviews live or plays recordings of customer interviews prior to doing this empathy map. Most likely these will be recordings as a live interview might be difficult. However, having live interviews with your sales or support team members might help a lot. They can bring to the project team their own experiences and understanding of customers and users. Once these interviews are complete, the group is ready to build empathy maps.

The person in the empathy map is fictional but based on understanding of the business’s customers. Ask the group to give this person a name and define their role with the product. The group will describe what the customer’s experience in each of the categories. Not everyone in the group will define something for each category but if a category is left blank, have a quick group discussion to try and fill it. It should take about 10-15 minutes for each customer/user profile.

The goal is for the project team to form some degree of empathy for the person, understanding at some level: What does this person want? What forces are motivating this person? What can we do for this person?


Who are our stakeholders?

Although the project team has met some stakeholders at the opening, the team will now identify all the stakeholders that have a direct interest in the project and those people needed to make the project successful. This can be by individuals or roles.

The project team members build a list of ‘Who’ and what they do or need to do to help make the project a success.

The group will spend 5-10 minutes defining this list. Have people fill out sticky notes and place these on the wall. Ask a volunteer to do some affinity mapping to group the item by the do’s.


The steps above can be reordered to suit your specific inception workshop need and your team’s baseline knowledge levels. If for example, the team knows nothing about customers, getting a base understanding of the customers through user journeys or empathy mapping before developing the elevator pitch might be the appropriate thing to do.

The steps above define the first half of the inception workshop. The second half has the team using the information gathered here to add detail for project planning and will include: Story Mapping to define the releases, provide high level estimates, identify areas of concerns and risks in Speedboats and Anchors, and provide the project team’s presentation back to the business leaders of what they can expect (and not expect) to happen during the course of the project.

Getting everyone on the same page and understanding the big picture doesn’t guarantee success but doing this can reduce truck loads of risk.

Some resources that can help you include:

Agile Development Teams and the Big Picture

Many of the developers I had known over the years loved the idea of creating a super amazing block of code and wanted nothing directly to do with the business. And in the past it was Ok because businesses didn’t need their developers to understand the business to be successful. More likely than not, business and managers told developers what to do and how to do it.

Today the world is changing and to be competitive, business cannot spend time telling the developers what and how to do their work. These days and for the foreseeable future, developers need to step up and take on additional responsibilities understanding what the work is so they can make good decisions on how to do it. Developers need to have that big business picture. And businesses need developers to have that big picture so they can contribute directly to the business, becoming partners with managers and business leaders, to be successful as one team.

If you’re a Scrummaster or Agile Project Manager, you’re probably spending time every day trying to find ways to improve your teams. If the development teams can be made to feel a part of the bigger business picture and can see on a day-to-day basis how they contribute to that big picture, they’ll make the transition from local thinking to system thinking, or sometimes stated as, “Think globally, act locally“.

Below are a few ideas for the Scrummaster and Agile Project Manager to consider around 3 key ceremonies of Scrum where a small change could make a big difference in the development team working in a global environment.

Sprint Planning

I’ve often been to planning sessions where both halves are more technical than is comfortably Scrum. The customer and the business value of the user stories at the top of the product backlog are rarely mentioned. The second half of the planning meeting is meant to be technical but not the first half. The first part of the sprint planning meeting is about user stories which translates to being about business and customers. The goal of the sprint is not about creating amazing technical solutions, the goal is about solving an amazing customer’s problem. The business plan is structured such that when we solve a customer’s problem, we help achieve a business goal. This idea is frequently forgotten and the sprint planning session is an idea time to reinforce why we’re doing the sprint in the first place. The desired outcome of the sprint is real value for the customers and real value for the business. Let’s not lose focus of this.

Scrummasters and Agile Project Managers ensure the development teams know and understand how the sprint outcome affects both customers and business stakeholders. Agile focuses strongly on the customer: Agile Manifesto-“Customer collaboration over contract negotiation” and the first Agile principle, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. But business is not forsaken with the Agile principle, “Business people and developers must work together daily throughout the project”. Every User story is (hopefully) traceable back to the business plan. The business plan or business goal is atop the columns in your User Story map as illustrated here.

The product owner presents both the customers’ and business’ point of view during the first part of sprint planning. The team creates a sprint goal that may encompass the customer goal, the business goal, or a combination of both. Measures: Use a sprint planning checklist of desired activities including why the sprint matters to both customers and business. Track adherence to the checklist.


I would speculate it’s a rare thing if a development team could not be more open, more transparent of their progress through the sprint. Although 15 minutes of each day is devoted to a one day planning meeting, the daily stand-up, the remaining 7 hours and 45 minutes of the day can seem mysterious to stakeholders and customers. “What is the team doing? How can I know they’re progressing?” are questions that come up a lot. Business stakeholders also want to know how the team is improving so they know this sprint is better than the last and the next will be better than the current.

Scrummasters and Agile Project Managers can help the development teams be more open and visible about sprint progress to the stakeholders. During the sprints, it isn’t always clear what features (Epics) have been done, what Epics & user stories are in progress, and which Epics & user stories will be next. Stakeholders cannot ‘see’ progress and results at a glance. By creating and maintaining a User Story map, prominently displayed on the wall, your teams, your managers, your project stakeholders, executive team can quickly assess what’s going on in the project. When I’ve done this, I’ve seen the CEO bringing board members to the wall to enlighten them on the business’s latest big project. Below is a nice graphic from Steve Rogalsky‘s blog post, “How to create a User Story Map”. If you look at the user stories within the release stream, you can see annotation for those stories in progress (WIP) and those competed (Done). When my teams did this, they also used colored dots to indicate the expected sprint.

The User Story map is a one-stop shop for project information. If you’re a large organization using the Scaled Agile framework (SAFe), User Story Mapping can easily be appropriated for Portfolio Kanban, Value Stream Kanban, and Program Kanban. Measures: For measuring the adequacy of visibility, it is likely that you’ll need to speak with stakeholders and managers alike to get their depth of understanding of the project. It would be best to gather this feedback while standing in front of the User Story map. Take special note of what understanding is missing so you and your teams can make any appropriate corrections or additions.

Scrummasters and Agile Project Managers ensure the development team is following highest engineering standards and highlight where these can be enhanced. In my experience, development teams can overlook the positive aspects of the more engaging engineering practices such as test driven development (TDD), pair programming, refactoring, and continuous integration. The main reason for abandoning these is usually time constraints. Development teams are pretty much working in ‘the here and now’ so it’s hard to convince them to do certain practices if short-term results are hard to see. To get teams to use these or other engineering practices, will probably require management support and very good measures to provide fast feedback. Pair programming is probably the hardest practice to implement but one of the easiest to measure using ‘cycle time’. Refactoring is also a hard sell to management and the product manager or product owner. Making code easier to read, faster to update, more efficient for tests, and easier to maintain doesn’t seem to have value if the code already works. Any effort refactoring appears to take away from doing ‘new’ work. Measures: The more immediate measure for refactoring is the reduction of tests, test cases, and the time it takes to run tests. Reducing test time for example should also make builds faster. Following cycle time for equally ‘sized’ stories is a good way to see if an improved engineering practice is having an effect.

Daily Stand-up

Agile and Scrum communities have made it very clear that the daily stand-up is not a status meeting but it usually degenerates into a status meeting over time. Managers demand to know status because, when they and other stakeholders attend these meetings, they don’t often hear anything of value to them. If the meeting included more about outcomes and team commitments it is more likely management will not demand the format be altered. Giving stakeholders the information they want and need can only make understanding and collaboration between development teams and stakeholders better.

Scrummasters and Agile Project Managers ensure the development team understands the value of the daily work being done. An easy way to do this is by having the development team relate their tasks to user story acceptance criteria. Another variation could be how tasks contribute to the goals of the sprint or vision of the project. I suggest using acceptance criteria as this is less abstract and less open to interpretation. Introduce a change to the Daily Stand-up meeting format so the team members talk about the value added. This is done by relating a task to specific acceptance tests/criteria. In other words, what acceptance tests currently failing will pass at the end of the day. This is the team member’s commitment for the day. In my experience, the development team saw this as valuable but more importantly, it made sense to them. A valuable side effect was the reinforcement of the boundaries of the user story. Relating work to the acceptance criteria each day helps keep customer and business value in everyone’s mind throughout the sprint. Don’t make relating a task to an acceptance test be a hard and fast requirement, some work may not directly contribute to passing acceptance tests, but the team should discuss the reasons after the stand-up.  Measures: One measure the team could use is the number of acceptance test cases passing, updated daily.

Scrummasters and Agile Project Managers listen to the team’s discussion during the Daily Stand-up and note when yesterday’s commitment wasn’t met because the task was bigger than expected. Team members make every effort to divide up work on user stories such that each task can be completed within a day (8 hours) or less. Although this isn’t an absolute necessity, it is in the best interest of the team and business to have this level of predictability. Help the development team break down work by viewing work from the core components of: coding, stubs and drivers, unit test, system test, acceptance testing, documentation, scrum of scrums (impact to other teams), and physical delivery. Tasks that unexpectedly take longer than a day can be the subject of team improvement within the sprint or a topic during the retrospective. Measures: One measure the team can use for managing themselves, with a little help from the Scrummaster, is how many tasks took more than a day to complete.


To get the development teams to meet business goals, it’s important that they speak and think in terms of business goals. Companies hire developers for their technical abilities which is important but companies also want these same developers to meet their business goals. The Scrummaster and Agile Project Manager can help develop global thinking within their development teams and the subtle changes above are a way to begin.



6 Steps to Prepare for a New Agile Project

In my previous post, 15 Steps to Agile Project Planning Success, I focused on the Inception workshop aspect of Agile project planning. Here I’d like to step back a bit and look at the steps and events that occur before the Inception workshop in a little more detail.

As Scrummaster or Agile Project Manager, you want your Scrum team to be successful and you’re probably willing to do most anything to see that it happens. One way to help the team be successful, and let the organization know what they can expect, is to do high level upfront planning.

The Scrum Guide gives lots of guidance on planning for Sprints, talks about Backlog Refinement in a side reference to planning, but doesn’t say anything about high level planning for the project. This isn’t the way it always was. Back in the 2010 version of the Scrum Guide you would have seen both Release Planning and Release Burndown charts. This was removed to highlight the fact that Release Planning isn’t necessary to do Scrum. It may not be necessary to do Scrum but hardly a business exists that doesn’t want some predictive means of future outcomes. This is where the Scrummaster or Agile Project Manager steps in and help make the Scrum team be heroes.

Any software project starts with a business need or goal. This might be playing catch-up with the competition’s latest release, customer feedback for product improvements, an innovative idea, a business’es desire to grow, or simply someone’s idea of what to do next. Some of these project ideas might be successful, some might be failures but all of them can benefit from planning.

Below are 6 simple steps to initiate your Agile project.

  1. Validate the problem and the solution
  2. Validate the feasibility of the solution
  3. Identify the Scrum team(s)
  4. Identify your key stakeholders
  5. Identify your key customers
  6. Create the measures for the project

1. Validate the problem and the solution

The first thing that should happen is validation of the problem your product has, and the solution. This part of preparing for your Agile project is the first instance where you hope to fail fast. Through validation you could easily discover your insanely great product idea is merely insane.

The problem is tied to the business goal the company wishes to achieve. For example, the business goal is to signup more subscribers. You theorize customers aren’t signing up because it’s slow and hard. Fixing this will result in more customers signing up because we’ll make it faster and easier to sign up.

This is also where you hope to fail. Failing here costs practically nothing compared to the cost of building an unwanted product. This step would generally be initiated by the Product Manager but involves development and the Scrummaster or Agile project manager. It may also involve other departments in the business like Sales and Marketing.

The easiest way to validate problems and solutions is through conversations with customers and users. Does your hypothetical problem and solution resonate with customers? If 2 out of 10 potential customers like your idea, that’s an interesting statistic. If 8 out of 10 potential customers love the idea, this is very meaningful and you are much more likely to have something worth pursuing.

2. Validate the feasibility of the solution

The problem and solutions have now been validated with customers and users. You now need to confirm if the company has the knowledge and resources to fulfill what the customers need. The development team validates that technically, the solutions can be done. The development team also confirms if they possess the required skills to solve it. This step will require some initial estimates made by the development team to check that the costs don’t exceed the potential benefits. Ideally, the Scrummaster and Product Manager have brought in at least one member of each team that could potentially work the project to provide these rough estimates.

This step is done as a research and prototyping exercise but needs to answer these questions:

  1. Can the work be done?
  2. How many teams will be necessary?
  3. What skills are currently available?
  4. What skills need to be learned?
  5. How long would it take to do the work?
  6. What does the high level architecture look like?
  7. What will I get at the end of the project?

If this is a massively large project requiring 100’s of Agile teams, the Product Manager, with the help of the most experienced developers, break down the work into something like “10 team” increments. For example, creating a product like Microsoft Office might require this to be broken down into smaller, more manageable chunks. These might be, Common Infrastructure, Word, Powerpoint, Excel, Outlook, etc. The goal of breaking down the work is so a small pod of teams (e.g. 10 teams) can work independently of any other pods if possible. Identifying independent streams of work will likely influence release planning later during the Inception workshop.

A note of caution on the estimates. If the estimate is 60 person months, that doesn’t mean 60 people can do the work in a month. The group working the feasibility of the solution should consider the maximum number of people who can work concurrently on the project. This means that special attention be given to any dependencies. In the group’s thumbnail architectural sketch they will need to factor in both serial and parallel development efforts before giving high level estimates.

3. Identify the Scrum teams necessary

Following on from step 2 above and assuming you haven’t failed the project based on step 2’s answers, the Scrummaster and Product Manager, along with development team leads, determine specifically which Agile teams are needed. This will take into account availability and skills but may also identify any necessary training. Although a project may not start with a full complement of teams, it is important that all teams be brought on-board for project visioning and the Inception workshop events.

4. Identify your key stakeholders

Successful projects depend upon a variety of people. The Scrummaster and Product Manager need to actively determine who their key stakeholders are and what their influence and interest in the project is. These stakeholders, usually part of the business hierarchy, have goals that they hope the project fulfills. You need to know this and actively demonstrate progress toward achieving their goals. You also need to identify any contradictory goals between stakeholders and resolve them now. These can’t be left to fester because they could eventually derail the project.

To resolve any conflict you’ll need to reestablish the business goal(s) the project is meant to meet. This will require the stakeholders and you to review the business goals, and how the project intends to meet them. A frank and open discussion will bring out the conflicts.  Ask the stakeholders to outline what they feel the goals are or should be. Compare those two opposing sentiments, and then explain how elements of each contribute to the business goals. Facilitate this meeting to achieve a lasting compromise of the details necessary to achieve the higher goals.

5. Identify your key customers

Identify your key customers or customer segments. You will need to figure out how to involve your customers in the project and keep them involved over the lifetime of the project. Put together plans to get customers to your sprint reviews, set up A/B testing strategies, or conduct user testing. Getting and keeping your customers and potential customers engaged will be a large factor in the projects success.

The Scrummaster and Product Manager will need a comprehensive plan to involve your customers. Some ideas could be:

  1. Create a project/product blog where status information can be radiated
  2. Get out of the building and meet potential customers at lunch. Show them your evolving product or website and gather their feedback.
  3. Invite customers to your sprint reviews.
  4. Conduct product reviews at a customer’s office if possible.
  5. Offer trial periods or beta products with opt-outs.

6. Create the measures for the project

The Scrummaster and Product Manager will need to know what success means for all stakeholders, customers, and other business entities including development. This is a project level definition of done and key tracking measures for each. This starts with the business goals and business requirements. A possible definition of done for a project could be:

  • Business goal of “increase males aged 25-40 sales by 35%” has been achieved
  • Customer feedback indicates the landing page is now appealing to both men and women shoppers
  • Business goal of a “12% increase of revenue” has been achieved.
  • Customer Net Promoter Score is above 73
  • Project team engagement score maintains a 90% or greater score

The definition of done should be as specific as possible to goals and customer problems but should not be so specific that developers and innovation are stifled. Your company should be encouraged to keep to higher level goals and outcomes and trust the teams to achieve these goals in the best way possible.

Once the business has arrived at a definition of done, this does not change. Changing the definition of done for the project might become very tempting to management as the end date nears. It should not be impossible to change this, just very, very hard.

Using the definition of done for the project as a guide, begin creating specific measures to track progress. You can start with the business goals. Take each business goal is break these down to the constituent components. Each component needs to be weighed for importance and prioritized. This is accomplished with select key stakeholders, customers, developers and anyone else who can help. The reality will be that people will find components of a goal that aren’t really necessary to achieving the goal. It becomes import to segregate the “wants” from the “needs”. You can use MoSCoW as a prioritization technique.

The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. Source: Wikipedia

Any details may be revisited & revised during the Inception workshop. What you don’t want to redefine is the project’s definition of done unless business goals become obsolete.

As an example, the high level measure for converting the landing page might be “how often male customers aged 25-40 click through from the landing page.” However, you’ll also need to include measures of all your other customer segments to check that you’re not losing their business in the process.

Plan and conduct the inception workshop

At this point, the Scrummaster (or Agile Project Manager) and Product Manager should be ready to run the Inception workshop. Be prepared to inspect the findings and adapt as needed. The best planning is flexible and welcoming of new found information, even if it reverses your thinking.

See, 15 Steps to Agile Project Planning Success, for more on running an Inception workshop.


Planning is important for project success but planning can’t guarantee success. One advantage to Agile planning will be a certain looseness and openness that can allow plans to change as more is learned. The more ridged the plan the more likely you will be to follow it even when good sense tells you not to. The point of the above steps is not to guarantee success but to find failure points faster.

A good plan is about removing or mitigating risks. Following these steps can help reduce risk.