Retained Projects
Retained projects in Basecamp have 2 Kanban boards: "Roadmap" and "Retainer Day Priorities". The general purpose of both boards is to provide everybody with as much visibility as possible over all parts of a project.
Roadmap
The purpose of the roadmap is to help clients understand how much effort is required to meet their goals and to help them prioritise the work that's done on their projects. This is done by giving them enough information to determine what they want to move forward with, and when they'd like to do it.
The roadmap board is split into 5 areas:
Note that tickets might not always move directly from one column to the next. A ticket might have enough information that it can be estimated straight away, or a ticket might be moved back into "Figuring it out" if more questions are raised during estimating.
Triage
This is a bucket for the clients ideas. Anything they might want in the future can go here.
Backlog
Once a client is confident that they’d like to move forward with a ticket, they move it into the backlog so that investigation can begin.
Requires more info
Often clients won’t immediately have all the information at hand for an accurate estimate to be provided for the work. When a ticket needs more info - the team should raise all relevant questions and move it into this column. This makes it easier for the client to see if they need to respond to anything.
Figuring it out
Once there is enough information to estimate a ticket it gets moved into this column. This lets the team know which tickets are ready for the next estimating session.
Estimate Provided
Clients need to sign off our estimates in this column before development work starts. If a ticket is going to take too long, they might decide it’s not worthwhile and move it into the backlog or drop it altogether.
Retainer Day Priorities
When a client has signed off on an estimate and wants us to work on it during their retainer, the ticket will be moved to the "Retainer Day Priorities" board. This board is to help everybody visualise the progress of tickets once they're ready to be developed. It's split into 7 areas:
Triage
Once an estimate in the roadmap has been signed off the ticket can be moved to triage.
To Do
Tickets in to do are ready for developers to pick up and work on. This list is in priority order, so developers on the retainer can keep picking up tickets from the top of the list.
In Progress
When a developer is working on a ticket it should be moved to this column. This gives everybody visibility on what tickets are being worked on at any point in time. It also ensures that a developer doesn't pick up a ticket somebody else is already working on.
Internal UAT
Once a developer has completed their work, if it needs internal testing it should be moved here. Not all tickets require this testing step. Work that affects mission critical functionality such as checkout changes should always be moved into this column. Otherwise it's up to the developer to decide if the work would benefit from an extra pair of hands testing it before the work is sent to the client.
Client Review
Once a developer is confident that a ticket meets client requirements and is fully functional it will be moved into Client Review.
When a ticket is moved here the client should be notified and informed of any useful testing steps. Typically this includes a link to a theme on which to test the feature, but might also include details on how to edit a feature, for example.
If a client raises an issue with a ticket or requests a change, the ticket should be moved back into In Progress whilst it's being worked on.
It is the client's responsibility to review tickets in this column and confirm if they meet their requirements. A ticket might not be moved straight from this column into Ready for Release, even if the client is happy with the work. Usually a ticket will only be held in client review after being signed off if the client isn't ready to publish it yet.
Ready for Release
When a client has reviewed a ticket in Client Review and confirmed it meets their requirements, they can move it to Ready for Release to inform us that they'd like the work to go live.
If a ticket has been in Client Review for a long time and is suddenly moved into Ready for Release, it is often worth an extra round of testing to ensure other work that's been deployed doesn't conflict with it. If there are issues the client should be informed so they're aware of the cause of delay, and can change their priorities accordingly.
Done
Once a piece of work has been deployed the associated ticket is moved into Done. By moving tickets into Done they can be rediscovered and referred back to in the future.