Definition Playbook

 

When building and delivering software you need to know what it is you are going to build and how you are going to deliver it. This is what Definition is for and this Definition Playbook helps you do Definition. 

Whether you’re agile, waterfall or somewhere in between, you still need to put the work in upfront so as to make sure you deliver what is needed. 

If you’re agile you’ll put in just enough work that you can start while continuously performing definition alongside development. If you manage waterfall projects you’ll want to make sure you have everything defined.

Here is where Definition fits if you’re building a new product, solution or platform:

What is Definition?

Definition is a phase of preparing for development, delivery or implementation. You review the problem, understand what can be done to fix it, design the physical and technical solution, and prepare for development to start. 

Definition is where you pin down the focus by making detailed choices on what will be in scope and out of scope. 

In some organisations, Definition is an isolated process completed all at once for multiple features or initiatives. In others, Definition is integrated into your continuous product development activities. Either way, the process of Definition is similar and bridges the gap between knowing the problem you want to solve and getting them ready to be implemented.

Definition will also help gain alignment across stakeholders by working through the details together and surfacing issues ahead of time.

On completion of Definition, you will have a view of the final estimates and timeline for completing development, and most excitingly, you will be ready to start building.

Why do Definition?

“If you fail to plan, you plan to fail”  – Benjamin Franklin

Doing Definition gives you the benefits of greater certainty over time, cost and scope. This helps you avoid or better manage problems like not meeting stakeholder expectations, running over budget, missing deadlines or not delivering that feature someone wanted in the way they wanted it.

Definition is the cheapest place to make mistakes and expend effort. As software gets built and development continues, changes become more and more costly. For example, it is almost 10 times more costly to make a change once something is in development than it is in Definition.

Source: Measuring the Impact of Changing Requirements on Software Project Cost: An Empirical Investigation

Key Concepts

The Key Concepts that are useful for Definition are:

1. Double Diamond – for context on where Definition fits.
2. User Story Mapping – a methodology for breaking down and visualise requirements.
3. Jobs-to-be-Done – a framework for framing Problem Statement(s). 
4. Product Roadmap frameworks – frameworks for defining your product roadmap
5. UML (Universal Modelling Language) – a method that is intended to provide a standard way to visualise the design of a system and the business processes around it.

There are also a number of concepts that will help in the technical design of a solution but are not covered because they are beyond the scope of this Playbook.

Key Inputs

The Key Inputs to a Definition are:

1. Business Case – the financial and non-financial justification for this initiative.
2. Problem Statement(s) – the problems you want to solve for users, customers or the business. This could be in the form of Jobs-to-be-Done if you’re developing a product.
3. Business Context – the aspects of the business that will drive the solution and its requirements, such as processes and regulations.
4. Product Roadmap – a list of the features to build and their priority.
5. Technology Environment – a description of the current technology environment, including existing architecture, data, systems, interfaces and patterns as well as any desired target state.  
6. User Personas – a description of who your users are and what they need.
7. Concept Wireframes – low fidelity wireframes that visually convey what the solution is looking to achieve.
8. Organisation Context – information about the organisation including practices, related programs, key stakeholders and the approach to governance.

Key Activities

The key activity streams are:

1. Business Analysis
2. Solution Design
3. Delivery Management
4. User Experience (UX) Design (optional)

Here is a visual overview of the work streams:

1. Business Analysis Steam

The purpose of the Business Analysis Stream is to understand the business and its requirements. 

Typically this includes these activities:

1. Understand Business Processes
2. Understand User Requirements
3. Understand Regulation 
4. Understand Non-Functional Requirements

2. Solution Design Stream

The purpose of the Solution Design Stream is to understand the technology environment and design a solution that will meet the requirements of the business.

Typically this includes these activities:

1. Review the Business Analysis
2. Design the Technical Solution
3. Identify and Resolve Key Technical Issues
4. Collaborate on Delivery Strategy

3. Delivery Management Stream

The purpose of the Delivery Management Stream is to manage the Definition activities so that they are conducted successfully while also planning how the solution can be delivered to meet the requirements of the business.

Typically this includes these activities:

1. Manage Definition
2. Engage with Stakeholders
3. Identify Risks
4. Finalise Requirements
5. Plan Delivery

4. User Experience Design Stream

The purpose of the User Experience Design Stream is to design the visual aspects of the solution. In its simplest form this is just about making the user interface look nice, in its more advanced form this is about co-designing the solution with heavy involvement from users. This stream can also be skipped, especially when developing systems that are more about process automation or APIs.

The simple approach to User Experience Design typically includes these activities:

1. Review the Business Analysis
2. Create Detailed Wireframes
3. Design the User Interface

The more advanced form of User Experience Design typically adds these activities:

1. Solution-focused User Research
2. Validate Wireframes With Users
3. Validate UI Designs With Users
4. Develop Clickable Prototype(s)
5. Validate Clickable Prototype(s)

Outputs

In general the core outputs you can expect from Definition are:

1. User Stories
2. Requirements Model
3. Solution Architecture
4. Wireframes
5. Delivery Plan 

Then, depending on how you conduct Definition, you may also get:

1. Technology Issues Register
2. Risk Register
3. Business Process Map
4. UI Design(s)
5. Clickable Prototype(s)
6. System Interface Definitions (API Definitions)

Read on:

• Product Discovery Playbook
• The Complete Checklist To Truly Understand Your Customer
• 3 Product Design Processes and When to use Them