You’ve taken the plunge and decided that your project is going to get the Scrum treatment. You’ve been on the course, you know the theory and higher management expects great things. So, where do you start?
Understanding Scrum Roles
First off, you need to make sure that all those involved in the project understand their roles and responsibilities.
The Product Owner
This person is ultimately responsible for the project. They are responsible for maximising the value of the product and the Team. They need to be prepared to give direction to the project, set objectives, identify requirements, assess change requests and prioritise continuously throughout the life of the project.
The Product Owner is solely responsible for the backlog of user stories which is used to document the product requirements. The management of the backlog requires them to prioritise stories in order of value delivered to the business to achieve its goals.
In most cases, this is a full-time role. The person filling the role needs to understand this and commit to the project. Whether they have a technical or management background, it’s important that they understand the business, understand what needs to be achieved and have the authority to make decisions.
The Scrum Master
NOT the project manager! The Scrum Master doesn’t make decisions and doesn’t manage the team. This is a coaching and supporting role.
The Scrum Master coaches the Product Owner and the team keeps them on track within the Agile framework and prompts people to make decisions.
During reviews, daily standups and retrospectives the Scrum Master will facilitate the meetings, making sure that the Scrum guidelines are followed and time-boxes are respected. They’ll ask questions that make the team think carefully about the delivery.
The Scrum Master will provide Scrum support to the Product Owner and help them manage the backlog. They will also act in a servant role for the developers and designers, helping to remove problems that block their delivery. It’s important that they keep an eye on stresses and pressures within the team and the project, and ask the right questions to help the team identify the problem and resolve it.
This is usually a combination of developers, themer and designers. The Team has responsibility for delivering the product and/or services.
The Team is a self-organised group of individuals that work together towards common goals. They’re self managed, with no project manager and have the responsibility for organising and delivering their work.
Collectively they commit to packages of work and deliver them as a team, not as individuals.
Don’t underestimate the burden that the Team is under. They have far more responsibility than the old-style waterfall team. With Agile, the Team is responsible for delivering the stories that they commit to. While this provides them with a sense of responsibility and achievement, they also have to deal with the stress that can be attached to the responsibility. It’s a far more interesting and involved role but the team need to be more driven and organised in order to achieve.
Understanding Scrum Responsibilities
The Scrum Master needs to take some responsibility for the product backlog, even if that just means encouraging the Product Owner to have it in good shape, well written and prioritised. Ultimately though, this is the responsibility of the Product Owner.
This means asking: Do the priorities match the project objectives? Do the prioritised stories add value? Are the stories well written so anybody can understand them?
Use a senior member of the team to check through the higher-priority stories before the sprint planning session, to make sure they all make sense, are clearly written and can be estimated by the team. This is called ‘sprint scouting’.
This session begins with the Product Owner describing the sprint objectives to The Team.
Next, they select all of the stories they want to include in the sprint, describing each one, in turn, to enable the Team to estimate on them. Once the team feels that they have enough stories to accept into the sprint, the first part of this planning session is complete.
The second half of the planning session involves The Team writing the technical tasks needed to deliver each story.
Once that’s done, sprint planning is closed and we begin the sprint in earnest.
Remember, sprint planning is timeboxed. Each session should be completed within four hours.
Every day during the sprint it’s important to check in with each other, to report on progress made and progress planned, and to raise any issues. This is done in a daily standup meeting, sometimes known as the ‘scrum’.
Remember to keep this standup session within the 15-minute timebox. Any additional conversations should be dealt with separately to allow those not involved to continue with their work.
Don’t allow anyone other than the Team to participate in the daily standup, although the
Product Owner should be there as much as possible — as a silent observer — to be kept in the loop. Leave issues & blockers for the Scrum Master to deal with, so the Team remains free to work.
Make sure to update the sprint backlog regularly so that progress in the sprint is clear.
A burndown chart is a tool used in Scrum to record and report the velocity being achieved by the team. I describe this in more detail in my Reporting & Monitoring post but essentially, it’s a graph that plots the required daily rate of burn, according to what the team accepted into the sprint against the actual daily burn of the team. This gives a visual indicator of whether or not the sprint is on schedule. We’ll also use information from the burndown to gauge our velocity for future sprints.
The Sprint Review
This review is the opportunity for The Team to show the client or stakeholders what has been developed.
It’s an opportunity for the Product Owner to present the project progress to the business and for content managers and users to ‘play’ with the functionality, to give feedback and for that feedback to be added to the product backlog if required.
Before the demonstration, have someone set the expectations of the audience. Ideally the
Product Owner will take responsibility for this because it’s their product and they have the responsibility to the users and the overall business.
Make sure you explain the progress that’s been made against the sprint objectives. This provides your audience with an understanding of why decisions have been made about the project priorities.
Often, end users are non-technical and don’t understand the extent of the progress when all of the design-focused tasks haven’t yet been done. The Product Owner needs to make them aware of the value that’s been delivered and the effect this has on them.
Make time to hold the retrospectives at the end of every sprint and at the end of the project. You’ll not improve your efficiency or improve your velocity without reviewing the way in which you approached each sprint and the overall project, so you can learn from mistakes.
Get everyone from the Team to discuss the bad (what do you want less of) and the good (what do you want more of).
Make sure to understand the root cause of any problems, so you can implement preventive measures and avoid them happening again.
Why not get feedback from the Product Owner? This is your customer and it’s important to understand their thoughts about the project.
If they have any concerns about communication or confidence in the project’s ability to deliver, then the sooner these are heard, the sooner they can be dealt with.