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 Team High Performance Communications

What is it that makes a development team successful? Is it their ability to accurately predict the delivery date?  Is it their ability to keep bug counts to a minimum? Or is it something else? Could it be how well the team communicates and works together?

Years ago the measure of a great development team wasn’t the team at all but the individual. This person would meet their schedule as shown on a Gantt chart and, maybe more importantly, did so without much intervention or guidance from their manager. They could make quick technical decisions and they knew the product and how it was used. These people were known then, as they still are today, as high performers. So Agile comes along and celebrates the Team, does this mean high performers are no longer wanted? Silly question, of course they’re still wanted. It’s really about definitions and what’s best for the business and for business growth.

The high performer of the past was always about the individual and less about the team. The appraisal systems in use then and for the most part still in place today, focuses on the individual’s performance. If the team results were less than stellar, the high performer was said to be held back by the other members of the team. Clearly it wasn’t the high performer’s fault the team sucked.

Now assume for the moment your business doesn’t wish to go Agile but wants to build teams made up entirely from high performers. This is exactly what Netflix has done (see the Harvard Business Review article, “How Netflix Reinvented HR“, for an eye opening insight on how this works). Now the kind of openness and honesty that Netflix has won’t work in all companies, especially if the company uses performance reviews as a weapon to elicit certain kinds of behaviors. So for those companies unable to go the Netflix route, Agile seems a good choice for company growth and building teams of high performers.

Agile is about teams and teams are made up of individuals. The high performer in the Agile sense is someone who helps make their team a high performing team. High performers in Agile are Servant Leaders, they serve the team first. They do this not by doing the work for those who need help, not by ignoring those who are weaker, not by telling the manager that this person is no good and needs to be trained elsewhere, but by showing the person a better way to work, by devoting time and energy to help those challenged, by working with management to train and build up the competencies of those in need. But how do these high performers learn the techniques and skills of helping, of being selfless, of being a servant leader? Enter the Scrummaster or Agile Project Manager.

The Scrummaster by virtue of training, study, reading, networking, and experience, is ideally suited to help those willing team members become great servant leaders. I say willing as some people will be pre-disposed to resist anything that distracts them from their first love, being developers. These people will need personal coaching to help them help themselves and grow their own servant leadership behaviors. The very first thing needed for any team to be successful is open and trusted communications. Below are 4 ways the Scrummaster can help build stronger communication links within the Agile team.

Team Communications

Most Scrummasters spend a considerable amount of time observing the team, how they behave toward one another, and how they communicate. Listed below are some of the behaviors I’ve observed and some suggestions on how to improve team communications. None of these are a one-off thing to do but will need to be repeated many times to change the team’s behavior. None of these are mandated but can easily be accepted by team member to varying degrees. Given time and patience, team members will build up toward being a high performing team.

  1. Development team members wearing headphones. This can be a bad situation as people are generally very courteous and often reluctant to disturb someone who’s wearing headphones. There’s no real good answer except to discourage, not necessarily eliminate, the behavior through team and one-on-one conversations. Some teams have set aside a “quiet hour” to solve this but this reaction can have a detrimental affect on open lines of communication and collaboration. Strike a balance where the team’s ability to collaborate and communicate are not stifled by someone wearing headphones. Make efforts to create tasks that easily allows pairing. Watch for the team member who appears to looking for help but doesn’t attempt to interact with headphone wearers.
  2. Team members who don’t stop working to listen. (This is about conversations within the team, not interruptions from outside the team.) Good face-to-face communications usually requires people to be face-to-face. The ability to make eye contact and observe facial expressions is important to help gauge emotion but it is also a sign of respect. When you stop and devote your full attention to someone while they talk, you are showing respect to them and the thing they’re talking about. I find that people are generally not aware of this behavior so I would suggest filming, with the team’s permission, how the team interacts during the day. When I’ve done filming in the past, people were very quick to see flaws in how they communicated and were able to make immediate and lasting changes.
  3. Team members who don’t know very much about each other. This may seem unnecessary to some but it’s really an essential ingredient for trust, empathy, and understanding. I was once helping out a Scrum team where there was constant fighting and bickering. This had a lot to do with people having their ideas and opinions ignored by everyone else. It mattered little that the person with the idea might be the subject matter expert because no one else knew that. I asked different team members what they knew of their fellow team members and it was shockingly little. One way to introduce people to one another is to do Journey Lines. I started a new project with several teams and we all did journey lines of our work careers to great success. People walked away saying they never knew or understood the depth of experiences some of their team mates had. I can’t emphasize enough the value of the Journey Line tool. It gets to the heart and soul of everyone on the team and once learned, you can’t go back. Below is an example Journey Line from Lyssa Adkins‘ book, “Coaching Agile Teams”.

    Source: “Coaching Agile Teams” by Lyssa Adkins
  4. Getting the team out of the office once a week. In my talk, “The Journey to Servant Leadership”, at Scrum Australia 2016, we encouraged people to do a team off-site once a week. Although our Scrum Australia talk was focused on transforming a manager into a servant leader, one important tool for getting the team members talking about decisions instead of the manager making decisions was this once a week meeting in a coffee shop. Part of the journey to servant leadership requires the team take on additional responsibilities and make more and more decisions. During these weeklies, the formality of the office hierarchy and structure disappeared and these team members spoke openly and honestly. The team members not only spoke about issues and problems they had in the office, they also talked openly about their families and weekend plans. But for the Scrummaster (or coach), this is a great opportunity to listen and observe how the team interacts and arrives at decisions. Back to the Servant Leader talk, my observation at the coffee shop was the team was unable to commit to a team decision even when it was overwhelmingly obvious they understood exactly what that decision should be. In talking to the team members later, the primary reason they didn’t make the decision was they feared backlash from the product manager. The decision involved fixing a problem the team had introduced in the previous sprint. The team needed to hear from the product manager that it was ok. This is all well and good in the Command & Control environment but is not the desired behavior in Agile. It wouldn’t fly at Netflix either. The team had to learn that collectively, they know more than the product manager and are better suited to made a quality decisions. The Scrummaster can use these off-site meetings to listen and understand team dynamics to spot areas for improvement. The team was having a conversation in the coffee shop they would normally not have in the office. Also, make sure the right people are there. If the team had the product manager in the coffee shop, the team decision would have been endorsed by the PM.


Building an Agile team of high performers starts with the individuals in the team. The Scrummaster can help build up their communication skills which is an important first step. Scrummasters will do and redo the above steps often as it will take time to get the team anticipating and understanding the wants and needs of everyone else on the team. This can take 3-6 months for most people in the teams to change although it could take longer.

Communications opens up many doors of opportunities not only for Agile teams but also for companies and company growth. A Forbes article, “Why Communication Is Today’s Most Important Skill“, author Greg Satell gives some historical background to great communicators. He also gives us some current examples of how business can flourish using communications.

The sooner people in your team and company are communicating, the sooner they can all be on the same page.


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.