Inputs to Build
Last updated
Last updated
To deliver change we have a clear process with Scrum. To support that process and the decisions made within it, we require certain inputs. These inputs are initially identified as part of the , are then tested and refined in , and will now be fed into the build phase in which the service will begin to be built to production quality.
While we focus the requirements on the user, the business will also have specific goals that it is trying to achieve through this period of change. Business goals could include increasing revenue, attracting more customers, or opening up their online business to a wider audience.
These goals will help us identify the high-level requirements that will need to be delivered in order to achieve the business goals.
All of what we do, the decisions we make, the solutions we develop, these are all driven by the needs of the users. The business sets itself goals but we need to understand what the users want in order to achieve those goals. If the business needs to improve sales then we need to look at what its users need to understand the opportunities we can exploit.
The discovery process takes a close look at the users. That process can include:
Interviews - discussions with users to understand their needs
Analytics - looking at how users currently interact
Observations - watching how users interact
There are many ways to tease out the needs of the user and the results of this user needs discovery will be fed into the project. Decisions and priorities will be based on that knowledge so having an accurate picture of those user needs is imperative if we're to get off to the best start.
Epics are high level requirements. These will be driven by the user needs. Once we understand what the users require then we can start to form meaningful epics that the delivery team can build on. The epics are the building blocks that we'll refer to and report on during the life of this change programme.
Changes are often subject to constraints such as time, budget and people. "This must be live before the Christmas rush" and "there is a limited budget for what we need to achieve" are typical of the types of constraints placed on any change programme.
Understanding the constraints up front enables us to plan around dates and to make the best use of the people and the budget available. It's better to go into the delivery with our eyes wide open and with an agreed plan for dealing with any such challenges.
As soon as we introduce budgets or dates into the equation then we introduce risk. The discovery will identify all types of technical risks for us to manage too. The delivery team will need full details of all known risks and any plans to mitigate before they begin the delivery phase.
There will be a process of prioritising the epics. When we work on the highest priority epics we need to break them down into smaller parts that can be delivered within sprints. Each user story will describe smaller, specific requirements that are the individual pieces from your epic jigsaw puzzle. The user stories defined will be placed in the product backlog where the Product Owner will define the priorities. For more details on how to write needs in this way, see our .
For a more detailed look at epics and user stories see
For more information, see