A Milestone approach to deadline driven projects - Part 2

A Milestone approach to deadline driven projects – Part 2

Rishi Sharma

Head Of Software Development, Tesco Technology

View on LinkedIn

A Milestone approach to deadline driven projects – Part 2

March 11, 2020 5947 Views

In the earlier part 1, we established the need for you to consider the milestone approach for the projects that are deadline heavy.

A milestone approach has two distinct phases –

Discovery Milestone (Product Driven)
Execution Milestone (Engineering Driven)

“Wait! What! we are not product, UX, Program, engineering, DevOps….. we are one team”, I hear you say as you start shaking your head vigorously dismissing the very premises of isolating teams and create divide among them. Not really. For Milestone process to work, you need to think of yourselves as many different teams who are brought together to deliver a project. This will force you to look at each team and answer the most important question:

How is this team going to keep the project on schedule?

Consider yourself as artist of this hugely popular stage play. Your role is agreed based on skills and you need to precisely deliver your dialogues at a set location on stage, at a defined timeline and with a defined pace. You are vital to the play however, for the play to succeed, it is necessary that all the rest of artists stick to their performance with absolute synchronisation.

A great way to decide which person from your earlier ‘One team’ becomes part of which smaller focused team, is to think replacement strategy. If you can write backend code but not UI then, you are part of the backend team. If you can write both – backend and UI code then you can choose either backend or frontend, and for that milestone your role is set. Same for UX, Product, Program etc etc. With that sorted, let us define some core terms which might seem familiar.

Epic:

An Epic compactly tells about the final output of user needs. Your product team translates an Epic into smaller manageable chunks called user stories.

User Story:

A user story clearly explain the complete flow for an end user. It is defined by your product team members in below format:

As a < type of user >, I want < some goal > so that < some reason >

It has three artefacts attached to it.

The narrative of the story
User Experience designs of the screens
Set of acceptance criterion to ensure that this story does what it says

User Experience Designs:

This is where a user story is visually represented as set of screens and flows between them. This is owned by your UX team and it contains:

User screens design and layout
To and from screen flows
Call to action for each screen
Interaction within screens and between screens

Backlog:

Product backlog is a place to organise Epics in a priority order to be picked up for discovery milestone.

Discovery Milestone (Product Driven):

The timeliness of a schedule is directly proportional certainty of detail in the specifications and estimates. So a date-driven discovery milestone begins with a groomed backlog, and below two definitions clearly carve it out for you.

Definition 1: The bare minimum work that must be done for this project to be accepted by end user
Definition 2: Number of milestones to finally realise the complete value to our end user. This becomes the release

Your teams then come together for one time inception exercise and agree on release and the count of milestones in the release. Now you have worst and the best case scenarios. During the discovery milestone phase, your teams will create first milestone and fully populated it sub-tasks and estimates. Your focus will be to use inception process to develop a plan with appropriate precision for the required deadline for the first milestone. So the steps for you are:

Divide release into multiple milestones
Estimate first milestones with certainty. Consider dependencies, deliverables, internal and external impacts, Epic sequencing, resource capacity and non-functional requirements
Spread rest of the Epics in logical order across remaining milestones and ask your teams to agree on dates for their completion. Remember you will reduce the scope if dates can’t be met

All your stakeholders come out of discovery milestone with below three accomplishments:

First milestone is fully estimated
The end date for rest of the milestones are set in stone
The stakeholder agree to iterate over remaining milestones until they are all ready for execution

Your product manager drives discovery milestones and ensures that until all the milestones are estimated, the teams are brought together and iteration continues once in two weeks.

Execution Milestone (Engineering Driven):

An execution milestone contains the Epics that are a result of discovery milestone. It is fully estimated by all stakeholders and ready for your engineering teams to develop and push for production. You get your engineering teams to slice stories in each epic and build your schedule by mapping out backlog on a timeline. Stories will contain tasks, estimated in hours and efforts for activities such as scalability, stability, security, maintainability, performance, and extensibility. Development will be differentiated by discipline, such as data model finalisation, service/API development, UI development, testing, security audit, deployment and bug fixes. The time-based tasks becomes building blocks to a predictable schedule.

To sequence tasks on the timeline, 2 week sprints will be used where you evaluate not only how tasks align with each other, but also with available resources. With preassigned and estimated tasks tiled out on a timeline, a backlog of milestone Epics looks like well-known traditional project plan. However, unlike traditional planning, you’ll be using a 2 weeks scrum mode to move your schedule into a series of pre-planned, equal-duration sprints. You’ll still start each sprint by validating your assumptions and recalibrating for unexpected changes in scope or complexity, but within the constraints of your end-to-end deadline.

One important activity you will do during milestone execution is to dedicate well called out time amongst stakeholders to refine future discovery milestones and improve estimates every two weeks. This should result in any call outs for reduction in scope if a date for milestone is being impacted as per the estimate provided by your teams. The precision of their estimate should reflect the degree of confidence in meeting a date, else scope is renegotiated and cycle repeats.

Summary:

To summarise a milestone driven approach, you break down the monolith waterfall and strive to achieve certainty of schedule via two phase approach mentioned above. A detailed plan for your team may look like below:

Above plan helps establishing accountability with the process owners and as part of respective teams, your stakeholder understand their role in the play. As long as each team focuses on successful project execution with common expectations and clear responsibilities, milestone process will end with fulfilled needs and satisfied customers.

Are there approaches that you have tried in your teams that have helped you deliver on time projects that are time driven ? It will be great to know your feedback and understand your perspectives on what has worked for you and what hasn’t. Learning is as valuable as the outcome.