Scrum is often the standard project management approach for software engineering projects, but it isn’t always a perfect fit in the real world. In my experience, very few companies do Scrum “by the book”, it is always adapted to best suit the project and company requirements.
Here is how I approach project management, heavily utilising Scrum principles with some fine tuning to better suit most software projects.
It looks simple but there is a lot going on in this diagram, so let’s break it down.
Project backlog
The project backlog is where all of the tasks for the project reside. It should be roughly in priority order. This is where each sprint is built from, so having the project backlog complete (as possible) and having accurate estimates is key to sprint and project success.
Building and maintaining the project backlog is a entire process of its own. I have written about a blog post on this topic – Agile Approach to Solutions Architecture.
Sprint planning
Planning is key to sprint success. As such, every member of the project team should be involved in deciding what is in the sprint and what isn’t. Each sprint should have the following:
- Clear goals.
- There needs to be clearly defined goals for the sprint, in order to consider it successful.
- Clear deliverables.
- Each engineer on the team, should have defined deliverables for the sprint.
- The deliverable doesn’t always have to be something you can deploy or release, but it should be something that can be demonstrated in the sprint showcase.
Sprint cycle
The sprint cycle is where the work is done, typically over a 2-week period. This doesn’t mean that the project team is just left to work on the project alone. There is a daily feedback loop that needs to happen, so everyone is aware of the project’s status.
- Stand ups. Daily stand ups are critical to maintaining good communication. Keep it brief but everyone should know what everyone else is working on and the goal for the day. Good stand ups should:
- 5-15 mins ideally.
- Each person should explain what they did yesterday and what they are planning to do today, in 2 mins or so.
- Stay on track, break out any further discussions into follow up meetings.
- Work. Each person in the project team works on what they said they would, simple.
- Update. Every task that was worked on should be updated every day. A short comment to document progress and optionally an update on time spent (if you are tracking that per task). Again, this is for good communication, so everyone has absolute clarity on a task’s status.
Sprint showcase
The showcase is where the deliverables of the sprint are demonstrated for all of the projects stakeholders. It is a critical part of communicating the projects progress.
It holds the project team accountable for their output during the sprint cycle and it shows the stakeholders the progress of the project and the quality of the work.
Ideally the showcase it done in person or on a video call / screenshare. Each member of the team should do a short presentation demonstrating what they worked on.
Following the showcase, final quality assurance and user acceptance testing can be performed. This is outside of the scope of this article, but it is an important part of ensuring the project success.
Sprint retrospective
Retrospectives are an important piece of the process, don’t overlook or skip them. It is easy to get caught up in the project work without taking a step back to see the big picture. The retro is the time to critically look at what is and isn’t working and to most importantly, improve things.
Don’t just focus on the bad, focus on the good too. it is important to recognise what went well, just as much as what went poorly. It is motivating to see that things went well, but just as importantly, it keeps everyone on track to maintain good habits/processes/workflows.
You won’t always have actionable outcomes from the retro. That is a good thing, it means things went well usually.
Tips
Involve the team. The entire project team should be involved in planning the sprint. If they decide what they will be responsible for delivering, they own it, they are accountable for it.
Be realistic. Don’t overload your sprints. If you are carrying tasks over into the next sprint every time, you are doing it wrong. If you always run out of tasks, you are doing it wrong. Measure, track and revise estimates so they are more accurate each time. This will give the best indication of the projects progress and timeline.
Don’t skip retros. The retrospective doesn’t produce any tangible output, so it is normally the first thing to get dropped from the process. Don’t fall into this trap, it is a critical part of the feedback loop. If you don’t do a retrospective, the process will never get any better and bad habits or patterns will continue to hold the project team back.
Accept change. Rarely do things go as planned, it is important to accept when things change and pivot to deal with the change when appropriate. This doesn’t mean that sprint goals, deliverables or plans change on a regular basis though. There needs to be a sensible middle ground.
Further reading – This is a great resource for understanding the traditional Scrum process – https://scrumguides.org/
