Delivery Phase

These playbooks outlines the different types of project management and software development processes we can offer clients, dependent on their needs. The goal is to price projects in a way that’s profitable, manages client expectations effectively, and reduces day to day stresses on everyone.

Projects are typically structured as follows:

1. Discovery Phase Learning, consulting, designing and scoping

2. Delivery Phase Development, testing and deployment

3. Maintenance Phase Bug fixing, maintenance, support

By knowing the customer’s preferred style of working, we can craft a good and profitable proposal built from suitable phased approaches to projects.

Our options are:

• Fixed-price waterfall deliverables
• Flexible agile retainer

Agile Retainer Delivery

Following the successful completion of the Discovery Phase, the project rolls into the Agile Delivery Phase. This phase is structured as a monthly retainer, providing the agency with predictable revenue and the client with the flexibility to adapt to changing priorities.

Instead of a fixed price for a fixed scope, the client pays a fixed monthly fee for a dedicated allocation of our time. This provides us with predictable revenue and gives the client the flexibility they crave.

Customer Profile

TODO

How to Structure It

Parameter	Proposed Value
Retainer Type	Prepaid Pool of Hours
Weekly Hour Pool	20 hours/week (It can be adjusted with 14/28 days’ notice.)
Monthly Billing	Bill for number of sprints, with hour pools within the last period
Hourly Rate	£50 + VAT
Monthly Retainer Cost	£4,000 + VAT (80 hours x £50/hour)
Overage Rate	£75 + VAT (50% premium on hours used beyond the 80-hour pool)
Billing Cycle	Invoiced at the end of the month with 14 day terms
Term	Month-to-month, with a 14/28-day notice period for cancellation or changes to the hour pool.

See here for what’s considered billable.

How to Sell It

TODO

How to Implement It

Jira Set Up

• Create a Jira board with the Scrum template to track sprint items and their statuses.
• Use a separate Jira board from any maintenance work. Each retainer should have a single Jira board.

Jira’s Scrum Template: https://www.atlassian.com/software/jira/templates/scrum

We’ll use Story’s and Subtasks to separate functional user requirements and developer tasks. It separates the “what” from the “how.”

Issue Type	Purpose	Audience	Details
Story	A single feature or requirement from the client’s perspective.	Client & Team	Written in plain English (e.g., “As a user, I want to be able to reset my password.”). This is the unit of work that is estimated (T-shirt size) and added to a sprint.
Subtask	A specific technical task required to complete a Story.	Development Team	Written in technical language (e.g., “Create password reset API endpoint,” “Build password reset form UI,” “Write unit tests for password service.”).

Use Jira’s built-in reports (like the Burndown Chart) and integrate with Clockify for accurate time tracking against estimates.

Client Visibility

The Jira Free Plan does not allow you to completely hide subtasks from users who have access to the project. However, you can achieve a similar result through board configuration and client training:

1. Board Configuration: You can configure the board’s “Card Layout” to only show the Story summary, without listing the subtasks on the card itself.

2. Client Training: Instruct the client to focus only on the Backlog view for prioritisation and the main Board view at the Story level. Explain that subtasks are the internal technical breakdown for your team.

Work Flow

Column	Status	Purpose
To Do	To Do	The sprint has started, and these are the Stories and Subtasks ready to be worked on.
In Progress	In Progress	A developer has started working on this task.
Code Review	In Review	The task is complete, and the code is ready to be reviewed by another developer.
In Staging (QA)	In Staging	The code has been reviewed and deployed to the staging environment, ready for final checks and client review.
Done	Done	The task has been fully completed, meets the Definition of Done, and the Story can be demonstrated to the client.

Sprint Process (2 Week Cadence)

1. Sprint Planning At the start of each sprint, review and re-prioritise backlog with the client. Apply estimates and pull in enough work to fill the 40 hours allocated for that sprint (20 hours/week x 2 weeks).

2. Sprint Development Work through the backlog, Novatura manages day-to-day developer activities through Scrum. Use test-driven development where appropriate.

3. Testing & Deployment Towards the end of the sprint, a few days before it ends ideally, changes should be tested and deployed.

4. Sprint & Review At the end of the sprint, demonstrate completed functionality, and move items out of the backlog. Regular feedback loop builds trust. Do the next sprint plan in the same meeting. Then run backlog refinement at the end.

Change Management is Dead: If the client has a new idea, it’s simply added to the backlog. There is no need for a change request, re-estimation, or re-quoting. The client is free to re-prioritise the backlog at the start of any sprint. They have full control over the scope, and you have control over the pace.

“Why hasn’t this feature developed?”

“You didn’t prioritise it. Next sprint, let’s bump up the priority.”

Transparency: Use Clockify to track all time spent on tasks. At the end of each month, you will provide a report showing the hours used against the hours pool. Transparency is crucial to maintain trust.

Defining “Done”

• A Story is only moved to the “Done” column if all of its subtasks are complete and the following criteria are met:
  • All necessary code has been written.
  • All relevant tests have been written and are passing.
  • The feature has been deployed to the staging environment.
  • The code has been reviewed and approved by at least one other developer.
  • Any necessary documentation has been updated.

The Ceremony: Review, Refinement & Planning

This single, efficient meeting with the client is the engine of your agile process.

Agenda:

1. Part A: Sprint Review (using the “Done” column):
   • Share your screen and filter the Jira board to show only the issues in the “Done” column from the completed sprint.
   • For each Story, demonstrate the working functionality from the staging environment.
   • This is a celebration of completed work, not a feedback session for new changes (new ideas go into the backlog).
2. Part B: Backlog Refinement (using the “Backlog” view):
   • Navigate to the Backlog view in Jira.
   • Review the flat list of Stories with the client.
   • Use Jira’s drag-and-drop functionality to prioritise the backlog in real-time. The most important item should be at the top.
   • For new or un-estimated Stories, discuss the requirements and assign a T-shirt size estimate (you can use a custom field or labels for this, e.g., “S”, “M”, “L”).
3. Part C: Sprint Planning (creating the new sprint):
   • In the Backlog view, click Create sprint.
   • With the client, drag the highest-priority Stories from the top of the backlog into the newly created sprint.
   • Continue until the team feels the sprint is full based on the agreed-upon velocity (e.g., the 20 hours/week for your current client).
   • Once agreed, click Start sprint. This will move the selected Stories to the To Do column on your board.

Sprint Retrospective (Internal)

This is not for the client. It is a safe space for the development team to discuss:

• What went well?
• What could be improved?
• What will we try differently in the next sprint?

This is what Friday review should be for.