Agile project planning using Effect Maps and Specification-by-Example - part 1

Effect maps are a high level project planning tool that can be used collaboratively by technical and business people to create a high level plan for the business functionality of a system, whilst focusing both sides on a single, tangible, measurable business goal.

I've recently adopted and been experimenting with a useful set of techniques for planning a website build. Each complements the other nicely and both serve as a blueprint for the business requirements of the site. They're perfect for Agile projects as they can evolve and change direction quickly as the project takes shape and can convey as much detail as the developers need at any given time whilst also providing the big picture to both product owner and client if appropriate. I've worked on numerous projects in the past where it is someone's job (often mine!) to write a detailed specification document before any development work commences. Usually that isn't practical and either development starts alongside the spec writing or the spec is incomplete and immediately out of date because the business requirements have changed. A classic waterfall problem. How then do you plan enough up front so you have the big picture mapped out enough and a clear direction to get you to your goal? In SCRUM we tend to plan an iteration or two at a time. Whatever Agile practice we follow we need to create and maintain a product backlog. How do we get stuff onto the backlog in the first place? Enter the Effect Map.

What to map?

Effect maps are basically mind maps focused on your problem domain. They enable you to drive out the business features in the form of specifications whilst not diverging from the core business reason that you are building the site in the first place. It's very easy to lose sight of that, even in the planning stages, and include features that don't really add any business value. Creating an effect map involves asking 4 key questions about the business driver for your project.

• Why are we building the project? What is the business goal?
• Who can help us achieve that business goal? Weigh up their relative importance
• How can they help us achieve the business goal?
• What can we provide them that will allow them to help us achieve the business goal?

So already you can see that every discussion you have is in relation to a single business goal. This helps you to stay focused. Let's illustrate this with an example.

Acme Inc. are about to embark on a new business venture. Some bright spark in the engineering department, perhaps in a fit of pique with clearing up after his pet dog once too often, has invented a brand new line in robot pets, which the company feel will revolutionise households across the nation. The chairman is already dreaming about the multi million pound bonus he'll receive for spearheading this venture. They are about to enter the final production stages of the first prototype and are turning to their marketing and sales strategy, the focus of which is an e-commerce site to handle the millions of orders they expect to fulfill. Considering themselves a forward thinking company, they decide to use effect mapping and specifications to plan the site build. They settle on a business goal that states "we want 1000 new orders placed through the site per day within 3 months of launch."

Having defined the goal, the next step is to define the stakeholders. After much deliberation they settle on new customers, returning customers, regional distributors, suppliers, Acme associates, Facebook, Twitter and LinkedIn. Reasoning that a robot pet is for life and not just for Xmas, they place new customers higher in importance than returning customers. They decide to focus most of their social marketing efforts on Facebook but will pay some consideration to Twitter and LinkedIn. The supply chain is very important if the goal is to be satisfied, but there is no need for a supply chain if there are no customers so they must come first.

The product team then sit down and map out how each of the stakeholder groups can help them achieve their goal and what they need to provide each group to enable it to help them achieve the goal. The resultant map is shown below.

The important outputs from this process are a set of features that can be used to drive the development of the site in a rough priority order. In my next post I'll show you how to flesh the features out as full blown specifications that can be used within your Agile process to drive the development and be the definition of done.

View original article