Home

Awesome

dwyl Process Handbook

Contains our processes, questions and journey to creating ateam.

This is very much a work in progress. Please add an issue for anything you would like to see discussed here!

All of this is predicated on the assumption that you care about your clients and you care about delivering quality code. Go into this with a positive attitude!

Contents

Introduction

This README covers the responsibilities and ceremonies of a scrum master.

Time needed to Scrum Master a project

Depending on the size of the team, scrum master work is likely to occupy 2-3 days per 10 day sprint.

This may consist of:

Responsibilities

So what is a scrum master responsible for?

Why? Developers may not know the status/details of all issues at all times. You must ensure that issues are ready to be worked on, whenever they come to them. This prevents time being wasted chasing or clarifying things when the team come to work on them.

A SM does not have 'authority' over the team, they work collaboratively with them. When the team needs direction to keep on track with the sprint milestone or with good gitflow practices they should be guided not forced! 😊

Ceremonies

Ceremonies are the events that the team take part in every sprint. Note: whilst valuable, ceremonies are just a portion of what it takes to run an agile project. Following the ceremonies in isolation does not mean you work in an agile way.

Stand ups

What is the aim of a stand up?

Stand ups are simple beasts, though often misunderstood. The aim of a stand up is a quick update for the whole team to ensure everyone is aware of what the team is working on, can understand where support is needed and ensure priorities are aligned.

Remember that 15 minutes of 4 people's time is actually an hour of time the client has to pay for.

A swift and focussed stand up is the key to a team's effective collaboration.

They should quickly cover what each team member has worked on since the last stand up, what they plan to be working on until the next one and crucially, whether there are any blockers.

A stand up is not:

Running stand ups

Each team member briefly summarises:

The scrum master should:

Sprint Demo

At the end of every sprint there is a sprint demo with the client. During the demo the client is shown the completed user stories for the milestone.

Sprint Demo Prep

Guidelines during the Demo:

The Demo

  1. Begin screen & audio recording
  2. Context of the sprint/demo
  3. Walkthrough of the product
  4. Review the stories completed in the sprint (let the person who did the work do the talking)
  5. Close the sprint milestone on GitHub (once all of the stories on the milestone are marked as complete)
  6. Wrap up the demo
  7. Invoice the client (ASAP)

Step 1 - Screen & Audio Recording

Before you start the demo start a screen & audio recording. It's useful in case you don't get the chance to write notes or if you need to share the session with an absent team member. Recordings can also help you review and improve your sprint demos for future instances.

Step 2 - Context

Start the demo by providing some introductory context such as what the aim of the sprint was and what you'll be demonstrating. The purpose here is two-fold; it sets up the demo but more importantly it allows attendees time to gently switch their attention away from their previous tasks (or meeting they have just come from), slow down and focus on the task at hand. If the demo isn't going to look like what the client was expecting (minimal styling for example), ensure that you explain this before you start so that they have a bit of time to digest why this is the case (reduce the shock factor) and what you're going to do about it.

Step 3 - Walkthrough

Walk through the proposed demo, paying close attention to:

Step 4 - Review the Stories

This part of the process will be repeated for each of the stories listed under the sprint milestone. Start with one story. For each story you have a couple of possible actions to take:

Estimating and tracking time is the single most important factor to manage in a software project, it's how we show the Product Owner / client that we are providing value-for-money and helps us to plan future sprints with any degree of accuracy. This is where other teams fall down.

Don't spend too long on each issue, whilst it's important to let the client know what progress has been made, make sure there's enough time left to cover the things that need their input and discussion.

In both instances ensure you mention what was learnt along the way.

Step 5 - Close the Sprint Milestone on GitHub

Once the previous sprint's stories have been reviewed and moved to the relevant places your milestone should now be 100% complete. At this point you should close the milestone on GitHub: please-close-completed-sprints

Step 6 - Wrap Up the Demo

Once you've completed your run-through of the demo, recap on what you've talked about and then ask if there are any questions (from either side). Discuss your plans for the next sprint in terms of deciding on a date to confirm a new scope of work. When you're finished don't forget to stop your screen & audio recording session.

Step 7 - Invoice the Client

As soon as the Product Owner (client) is satisfied that the agreed stories for the sprint have been delivered, prepare and send the invoice before anything else. NB. This may not fall as the responsibility of the SM.

Retrospective

Sprint Planning

Spring planning is when you review the backlog and client's priorities to outline what will be put into the next sprint milestone. This may be done immediately after a sprint demo and retrospective or otherwise on a time/date agreed at the end of the sprint demo.

Sprint Planning Prep

During Sprint Planning