I became Scrum Master in team BAR in Fribourg back at the start of June, and over the last 3 months I've learned a huge amount about Scrum and I'm really happy with the way my team are working. Since I have contact with a wide number of people, both in the open source world, and people I've worked with in previous positions, who are interested in Scrum, I thought I'd write a blog post describing how we work, and what I like about it.
Roles
Scrum Master
The primary role of the Scrum Master is to make sure that the whole team adheres to the Scrum Methodology. They are also responsible for removing impediments that stop the team working. In practice this means that I have to move the meetings along, make sure that the Sprint goals stay consistent and help the team do whatever is necessary to achieve them.
The Scrum Master can be a programmer in the team, and I am, although depending on the size of the team and project, how much I can really do varies quite a lot. During the last project, we had a big team of up to 9 people and I didn't get much chance to do any programming, but instead was just doing code review and helping people solve problems.
We tend to have senior developers taking on the Scrum Master role, which means that often the Scrum Master tends to be a bit of a technical lead. Many people think that isn't ideal for a Scrum team, and for good reason. Ultimately I think it's ok, and has been working well in our team, as long as the Scrum Master doesn't take on large tasks that would cause them to lose focus from their duty as Scrum Master, because that is of course their primary role.
Product Owner
The Product Owner role is actually split in two – the Product Owner, who is from the client, and an internal Liip “Product Owner Assistant”. My main Product Owner Assistant has been David Buchmann. The role of the Product Owner Assistant is sort of the flip side to the Scrum Master. While the Scrum Master takes care of the interests of the team, the Product Owner Assistant's responsibility is the product, and the Product Owner at the client.
The Product Owners are responsible for creating the backlog of User Stories for the team. This backlog must be prioritised and each User Story must be small, complete, understandable and non ambiguous. In other words, ready to start work on. Basically, the Product Owners together are responsible for the functional description of the product the team is going to build. These User Stories are typically something like: “As a
The relationship between the Product Owner Assistant and the Scrum Master is an interesting one, and I think one that David and I managed to figure out to a really good degree. There must be a huge amount of trust and respect between these two people, the Product Owner Assistant must trust the Scrum Master to be able to make sure the team is working efficiently in a way that will result in high quality work, and the Sprint Goals being met. The Scrum Master must trust the Product Owner Assistant to make sure all the requirements are expressed and the functional implications of everything has been thought through. Of course this follows through in both directions to the Product Owner at the client as well.
Team
The last role is the most important one – the team. The team are the people who build the product and are responsible for demonstrating the features they built to the Product Owner(s) at the end of each Sprint. They should self organise and figure out the best way to allocate and take tasks on to reach the Sprint Goals. When I first became Scrum Master, it was very difficult for me not to suggest what they should work on, and over time I tried to really force myself to not do this, but instead encourage them to self organise. In that way the role of Scrum Master is really like a facilitator.
In our main project over the last three months, we had two external developers from the client as part of our Scrum Team. I was very impressed with how well these two were integrated – they were 100% part of the team, just as much as any of our internal developers. I think Scrum is a huge part of why it worked out like that. They took part in all the meetings, paired up with internal developers to work out hard problems, and were just as responsible for the Sprint Goals as anyone else.
Meetings
The life of the project is divided up into Sprints. We've done both one week, and two week sprints, and I personally think two weeks sprints are ideal.
In order to keep our team focused on the Sprint, all support tasks and maintenance issues for older projects get pushed to “Support Friday” (assuming they are non-critical, but we do have a support team to deal with critical stuff as well, and they only escalate issues that need developer help to us). This has been quite a revelation for me, as I was always one of those people who were working on, or responsible for, about 8 different things at once, and finding the time to really get a deep focus has been very difficult. Of course in my role as Scrum Master, I don't really get much opportunity to get this deep focus anyway, as I'm always running about helping people and removing impediments, but at least that way, the rest of the team is focused during the Sprint, except for Fridays, which are dedicated to multi-tasking and distractions anyway.
During the Sprint, there are a number of meetings. To the uninitiated, it seems as though Scrum is very heavy on meetings, but in reality I think the cost is worth it because of the time savings of everyone knowing what we're doing. And most of the up-front project planning is removed with Scrum, saving quite some time and costs.
Estimation Meeting
The Estimation Meeting is about going through the backlog of User Stories that the Product Owner or Product Owners prepared, and discussing them to a point that the whole team has understood them, and then estimating each story. The entire team, the Scrum Master, and both Product Owners attend this meeting.
The User Stories are estimated using some arbitrary scale called “Story Points”. We've completely stopped doing time estimations in our team at all, which felt extremely weird to start off with, but is now fantastic. A Story Point is some relative scale of “amount of effort”. We used to rate them on “complexity”, but have since realised that some things are not complex at all, but still take a long time, so we stabilised on “effort”. These must be relative to each other, and usually we achieve this by taking some reasonably small story and calling it a 3. Then everything is estimated relative to this.
We do the actual estimations using a technique called Planning Poker. Every team member (except for the Product Owner, and I usually stay out of it too unless I'm really working as a developer on the team), has a set of cards with a number on each one. The numbers start off following the Fibonacci sequence until 13 at which point they deviate to 20,50,100. We also don't have two cards with a 1, so it's not true Fibonacci. Then we have a ? card and a K card, which mean “no idea” and “coffee break!” respectively.
We have the current User Story up on the wall somehow, either projected or a printed version, and we all read through it and discuss it until we're ready to estimate. Each person throws out a card when they're ready (number face down) and then they all flip them over together. This is to ensure that, for at least the first round, people are not influenced by the opinions of everyone else. We then pick out the person with the lowest and highest estimates, and get them to justify their case. This usually leads to a good discussion, and then either eventual consensus (with or without another round of throwing out cards), or if it seems like it's going on too long, or is unlikely to reach consensus, I stop it and we take the highest estimate still on the table.
When we first started, Estimation Meetings were really taking a long time, and we have tried a number of approaches to make this more efficient. I don't think we're there 100% yet, but we've certainly improved. We usually have our estimation meetings in the afternoon, and have so far tried:
- The whole team individually reading through the User Stories to be estimated in advance (the morning of the meeting) and asking clarifying questions to the Product Owner.
- The team dividing into pairs and reading through a percentage of the User Stories in advance
- The team dividing into pairs and reading through all the User Stories in advance
All of these have pros and cons, and we seem to have settled on the third, since it has the best way to promote discussion (pairs) but also still prepares everyone to be able to estimate all the User Stories. However, this point really highlights the need to have very clear User Stories in the backlog. We have definitely learned that we need to work with the Product Owner a lot to help them write User Stories in a way that we can easily estimate without meetings that take forever.
This also means that the internal Product Owner must be able to push back against the Product Owner at the client, to force them to make decisions and have all the information we require ready before we start.
Sprint Planning I
The next meeting is Sprint Planning I, which tends to go pretty fast. This usually follows directly after the Estimation Meeting (with a quick coffee break in between to give everyone a rest). The purpose of Sprint Planning I is to define the goals for the forthcoming Sprint. Since we've had the estimation meeting by this point, and usually know how many story points we can fit into a Sprint (more on this later), this is usually very simply done by just putting the next n highest priority stories into the upcoming sprint, to a point where the team can commit to the Sprint Goals without feeling overloaded. There's usually a bit of to-and-fro-ing at this point to decide exactly how much we think we can take on, but it's quite straight forward. We also put a couple of extra User Stories into the Sprint, but call them “nicetohaves”, which means they get planned out as well, but we only start them if everything else is done early, and we don't fail our Sprint Goals if we don't get to them, or don't complete them. The nicetohaves are usually the next highest priority stories that would go into the next Sprint.
Sprint Planning II
After Sprint Planning I, I usually rush off to my computer while everyone else gets coffee, and print out all the User Stories that have gone into the next Sprint. We use JIRA for tracking all of this, although it's usually not used by the team at all, just by David and I for tracking and reporting. Pierre wrote me a Javascript “bookmarklet” for Firefox, which takes a JIRA page and formats the most important information in a nice printable way.
The team and I are now ready to go into the next round of Sprint Planning, which is technical, and therefore doesn't involve the Product Owner, although they must be available to answer functional questions as well. To do this, we go into a meeting room with the printed User Stories and a pack of Post-It Notes. For each User Story, we try to list all out the technical tasks (one per Post-It Note) required to complete the User Story. I usually write the JIRA issue number, which is on the printed User Story, on the top of each Post-It Note and then a summary of the task. For some reason they really don't stay attached to the whiteboard, and each morning I came in to have to put them back on the board. We now actually use sellotape to attach each Post-It Note, which I find infuriating.
At the end of Sprint Planning II, we therefore have a number of Post-It Notes for each story, and I'm ready to prepare the board.
For more about the Scrum board, and the rest of the Scrum Artefacts and meetings, stay tuned for the second part of this blog post!