We've created these processes to solve some of problems we have experienced as a team when working on projects together. It's recommended that you start a project using these processes as a starting point and alter them to fit your team.
This is a guide, not a rule book. Just like everything we do, if it's not working for your team, change what you're doing.
Most of the problems we've come across can be split into a few themes:
Making sure everyone in the team has access to the relevant information and knows where to find this information. Information such as user stories, contracts with the client around scoping and pricing, clients contact information, meeting notes with client, what tasks team members are working on. If this information is easily accessible by everyone then it creates less context-holding by 1-2 core people (centralized dependencies) and less disruptions and blockers for developers through the project.
Setting up a rhythm at the beginning of the project is key to keep the momentum going throughout. Things like regular stand-ups at the same time every day and regular contact with the client can have a big impact.
Technology is Hard, But People are Harder
- We've received all source code
- We have access to Staging and Production environments
- We have a local development environment set up
- We know the deployment process and ideally have deployed a small change to test/verify it
Most of these items should be done during Sprint Planning. User stories should be created before this meeting and this meeting should be working out the weighting of each ticket and getting team members up to speed with everything.
- Scope is agreed on and signed off with client
- User stories are created into tickets (online or physical)
- Tickets are weighted
- Tickets are prioritised, ideally by client
- Tickets have blockers if more info is needed
- Definition of weighting created for a ticket (What's a '1'?)
- Definition of 'ready' created for a ticket
- Definition of 'done' created for a ticket
TODO: A guide on how to do stand-ups
- Daily stand-ups. Ideally, same time every day
- Ideally have a stand-up with the product owner/client daily or as often as possible. This stand-up does not have to be with the whole dev team and can be just the project manager and client. This standup is mainly to get over blockers quickly and to keep the client in the loop.
- Having an external scrum master that's ideally a developer/technically minded.
- Hand over code and backlog of bugs
- Retro
- Sign off from client