Build Kickoff
Once we agree a programme of work the next step is usually an intense discovery process to map out processes, to look at possible solutions and to identify the high level requirements (epics). At the end of the discovery process the next step is to move to the delivery phase to begin the process of developing what's been agreed.
It can be daunting when you first begin any project or change programme. The expectations are high, there is excitement among those who have been involved in the process so far and it’s your job to pick up the baton and see this through to the finish.
Before anything starts it’s good to begin by sitting down with the Product Owner to talk through the work and what they can expect. There is no harm in going over some of the requirements that have already been discussed.
You will need to be clear about both of your positions, where the responsibilities lie, setting out the approach the team will take, how the epics will be prioritised, broken down into stories and then further down into specific tasks. Explain the product backlog, why this needs to be reviewed and updated regularly. Make sure the Product Owner understands Scrum and specifically what is required of them. These changes are your joint responsibility. It's imperative that you both understand and agree the approach.
You'll be meeting with the client regularly so now is a good time to book those initial meetings, get the dates in people’s diaries, get the rooms booked and make sure there’s nothing obvious that can get this project off to a bad start. Explain why the meetings are important and how they will affect the life of the project.
There is work to be done before we can move into the delivery. First of all we need to carry out a discovery phase:
Introductions - introducing the client to the project delivery team
Project team - key contacts within the client
What is the current process (assuming one already exists)?
Who are the users?
What is driving this change process? What do the users want or need?
Business and project goals - why are we doing this?
Budget - how much do we have to deliver with?
Schedule - what are the key dates?
Risks - known risks to manage, mitigation already identified
The discovery is all about mapping processes, looking into the purpose of those processes and investigating new and better ways to achieve what needs to be done. Generally there is a lot of drawing on whiteboards and using postits to illustrate processes and that approach tends to encourage people to get involved, to listen and to share their ideas.
The output from a discovery are the epics, the high level requirements that the delivery team will work on.
For a more in-depth look at what's involved take a look at the Discovery pages.
The epics are like chapters in the project story. They identify the structure of the story that you're going to tell. Although the order of the epics might have been agreed during the discovery, once the team have looked further into the details of how they will be delivered, the identification of vulnerabilities or dependencies could mean that you need to switch some of those epics around. Of course, all of this will be agreed with the Product Owner.
An important point to stress is that when the priority of epics is set, that doesn’t mean they’re set in stone. Making that point to the Product Owner can help you progress more quickly when they understand that the decisions they make today can be changed tomorrow or next month as requirements change or as you react to new information.
We’ll be reporting on the status of the epics throughout the project when we meet with the stakeholders so it’s important to be clear about how those epic fit into the planning, those which are complete, those which are in progress and those we’re planning to work on next. It may be that some epics are not delivered because we can expect the requirements to change, particularly on a lengthy change programme, but it’s important to be able to explain this and the reasons around it.
Once you’ve selected the highest priority epics then it’s time to begin the process of breaking them down into manageable stories and building your initial product backlog.
The development will begin with a planning session in which user stories are selected, discussed and then worked on by the team. Before we get to that point, we need to take our epic, break it down into user stories and those stories will form your product backlog.
At this point we need to take epics such as “create a digital community” or “integrate the back end with the warehouse” or “implement shopping basket” and break those down into individual user stories that individual members of the delivery team can deliver.
If you take the shopping basket epic as an example then you’ll need to look at how that breaks down. E.g.:
What specific functionality do the users need?
What devices does this need to function on? Desktop? Mobile?
What are the use cases?
What are the payment options?
Does the user need the option for a re-order?
Does the user need to see shipping costs?
Should there be a gift wrap option?
When you begin to break down an epic into specific user stories you begin to understand how big a seemingly simple epic can be. Breaking the epics down is another great way to fully understand what’s being asked for and to identify which of the requirements are a priority, which will deliver value and which can be pushed back for a later sprint.
Approach the break down of epics with a fist full of posit notes and a blank wall. Display all of the stories on the wall, discuss them individually and score their value, their priority and include an initial estimate of effort too. Understanding the correlation between effort and value can help the client to make decisions about key functionality.
Once you’ve discussed all of the stories in detail write them up into user stories. Include any supporting information that might help the team understand the reasoning behind the story. They will need to make decisions about their approach to the story so it’s important to understand how it fits in with the overall objectives so they can decide on the best approach to take.
You’ve talked the project through in detail, you have a very clear understanding of what needs to be achieved and, armed with your user stories, you can now build up the initial product backlog ready for the first planning session to kick start the first sprint.