Many clients struggle with the concept of Agile-Scrum. We need to put measures in place to reassure them that the project is properly managed and controlled, and to demonstrate the value that Agile-Scrum brings.
The product backlog is easy to understand. It’s the path to user acceptance and project success. Maintaining this correctly shows clearly what’s been achieved together what’s due to be achieved.
The Scrum Master needs to push the Product Owner to continually review this backlog to make sure it’s current and the priorities are set correctly.
As epics move up the list we need to make sure that time is spent breaking them into smaller stories ahead of the planning session, to make that session as efficient as possible.
Value can be assigned to user stories to quantify progress and build metrics used for reporting to the business.
Sprint burndown charts
Sprint burndown charts show sprint progress at a glance. Most Scrum tools will provide a means to create these, or you can create them easily in Microsoft Excel or Google Spreadsheets.
The purpose of the burndown chart is to show the number of points the team has accepted into the sprint and the required daily average to achieve this.
The actual number of points burned every day is plotted against the graph to show progress.
It’s a very simple way to track progress and gives an early indication of what the team is likely to achieve in the sprint. Having this visible provides us with the knowledge required to re-prioritise if necessary.
The Team and the Scrum Master are jointly responsible for updating progress daily in order to create accurate burndown metrics.
Risks are often considered but not properly measured or managed. They need to be considered, logged and tracked in a formal schedule before a project begins.
Logging the risks is the first step. Assigning responsibility, assessing, mitigating, and maintaining a review and action schedule is vital to the success of the project and for client confidence.
Risks can, and should, be discussed. Making the team, the Product Owner and the steering group aware of them and planned mitigation gets them out into the open and generates discussion.
Be open about risks, share and gain input where available. A risk shared can be a risk halved.
Capture your sprint estimates and review them at the end of each sprint. During the retrospectives use your time to understand how accurate your estimates are.
Try to understand the causes of any anomalies you see and implement changes to help you become more accurate.
By estimating accurately you set customer expectations at a level that can be achieved.
Challenges to improve
Scrum provides the checkpoints to allow us to review progress but it doesn’t force us to do so. After all, it’s a framework, not a methodology.
We need to implement our own goals and objectives into projects in order to set ourselves challenges to improve.
Take the time to review all of the key steps in the project, put in place plans to manage and improve each of them, and generate accurate data for the client.
These are not big overheads. They’re easy to do but the benefits can be huge because your actions will go a long way in your relationships and towards your ability to succeed.
In summary, we add much value to our Scrum projects through clear reporting. The backlog is our requirements list and we need that backlog to clearly report the priorities.
Risks are simply obstacles designed to prevent us from achieving a goal. Manage the risks properly, share them and be ready to react when the risk increases.
Record and review your velocity regularly. The client will appreciate the openness and will be more than satisfied when you’re able to report increased velocity as the result of process improvements.
Your ability to set accurate expectations will take the pressure off the team and allow them to focus on delivery.
Record, report, review and improve to add real value.