This post forms the second part of a two part blog post about how team Fri-Bar does Scrum. For the first part, go here.
Artefacts
At this point I'm going to digress from explaining the Meetings (yes, there are more!) and talk instead about the Sprint itself.
The Scrum Boards
The Scrum Boards are the most important artefact (in my opinion!) in Scrum. We have a total of four boards in our team: two Sprint Boards, one board for Support Friday, and one information board. I found myself standing in front of the Scrum boards in the mornings, which gives me a feeling for how we're going, and for a long time I couldn't figure out what it reminded me of, but eventually I realised it was the exact same way that the surgeons in Grey's Anatomy stand in front of the surgery board (yes, I know I am admitting to having watched Grey's Anatomy – no judging!)
Sprint Boards
The Sprint Boards are for tracking where we are with the User Stories in the current Sprint. They're a portrait-style board (we use whiteboards), divided into three columns – backlog, in progress, and done. After Sprint Planning II, I stick all the User Stories and their tasks (on Post-It Notes) into the backlog. These are in descending order of priority. We have two Sprint boards because with a big team and 2-week Sprints, one was not enough.
Support Board
The Support board is basically just a mini Sprint board, for all the tasks we have coming up, in priority order. We only use this board on Fridays although I stick new tasks to it as they come in from our Support Team.
Info Board
The Info board is also important. There are three main things on the Info board:
The Sprint Burndown Chart
At the beginning of the Sprint, we know we have some amount of Story Points to burn through to reach our goals (we don't include nicetohaves here). Say 50 points. I make a little graph, with Story Points on the y axis, and days on the x axis. Each day after the Daily Scrum Meeting (more on this in a little bit), I plot how many Story Points we've managed to finish. I only track completed User Stories, for example if we have a 4-point story that is half done, I burn down 0 points for it, not 2. The Burndown Chart is a great way for everyone to see how we're progressing through the Sprint.
The Velocity Chart
The Velocity Chart is another interesting graph, but this one measures our progress over a longer period. The velocity is how many Story Points we manage per sprint. We don't include any Story Points from any failed User Stories, but we do count nicetohaves. I usually also plot a bit more information in different colours:
- Committed-to Story Points (doesn't include nicetohaves)
- Achieved Story Points
- Person days in the Sprint
It's unfortunate that we have the last one – a Scrum team should really be consistent each Sprint, but since I've been Scrum Master over summer, we've had people on holiday, and this number has fluctuated quite a lot.
The Product Owners tend to carry in their head the ratio between time and story points (read: money) for budgeting reasons, but I force myself not to think about this. I actually really like the abstraction of Story Points. At any rate, this tells me how efficiently the team are working and whether we're improving, and it helps us figure out how many Story Points to commit to in a Sprint, while at the same time helping the people who have to keep track of budget.
The Calendar
I've recently started drawing up a mini-visualisation of the days in the Sprint on the board (we tend to divide up boards using bright blue tape), and then everyone can stick Post-It Notes there for days they'll be off or out or have something else to do. In our next project we'll have two team members coming from Zürich, so it will be a good way to get a quick overview of who is when, where.
Other Miscellaneous Information
We also track things on the Info board like the DDOD (Default Definition of Done) – that is, unless explicitly stated, what needs to happen for a User Story to be done. This usually has at least:
- Code committed to version control
- Deployed to development servers
- Documented
Our team has a 5 CHF penalty for being late to the Daily Scrum, so we also track debts on the Info Board. We give our penalty money to http://www.kiva.org/
The Surrounding Walls
One of the projects we've worked on this year had a lot of printed material which we stuck to the walls. This included flow charts and screen shots, and I found having these visually available through the whole project to be incredibly useful.
Meetings Part II.
Yes, back to the meetings
The Daily Scrum
The Daily Scrum is probably the most famous meeting, and in teams which are starting out doing Scrum, it's usually the first one to be adopted. The Daily Scrum is a “stand up” meeting, to make people keep it short. We have a talking “stick” which is actually a pony, which we pass around, while we talk about:
- What we did yesterday
- What we're going to do today
- Any problems we're having
The Daily Scrum meeting is theoretically the only time that Post-It Notes get moved between backlog, in progress, and done. I say theoretically, because it does happen that someone finishes their day's work quickly and moves another task from the backlog into in progress, but the important point here, is that we don't move tasks into Done without transparency to the rest of the team. When a task moves from the backlog into in progress, the person taking it has to put his/her name on it.
As I said, one of the most important things about Scrum is self organisation. This means that people need to work together to get a User Story done, and the Daily Scrum is the time to figure out the best combination of people to do this.
When we started, we were doing what I would later learn is called “Water Scrum”. Water Scrum is when you have almost the entire Sprint in progress at the same time. It is named after the Waterfall method, which Scrum is really supposed to be the antithesis of. The problem of Water Scrum is also of course the same danger of Waterfall, which is that if you have everything in progress, but nothing complete, when time runs out, you fail everything, rather than just one or two features. We aim as much as possible, to complete User Stories before starting the next ones. This means if we run out of time in the Sprint, we will at least have some complete User Stories. It's very difficult to not do Water Scrum with a large team, because it's really quite unfeasible for 9 people to work on a single User Story, but we do try and minimise it wherever we possibly can.
At the Daily Scrum, we also track the completeness of whole User Stories. If all the tasks for a particular User Story are moved into done, that means the story is complete, which means that someone has to take responsibility for re-reading it, testing it in the environment that we're targeting for demonstrations, and ultimately, demonstrating it to the Product Owners in the Sprint Review. We mark tasks as complete with little green arrows that we stick on the User Stories, and at this point write the name of the person responsible on the arrow too.
Another thing that can happen in the Daily Scrum, is that we realise something is blocked. This might be for technical reasons, like not having access to a server, or something else, like we need more information from the client. To indicate this, we stick a little pink arrow (as close as you get to red in Post-It world) over the task (or User Story) to make this very obvious as well.
As you can see, we do Scrum in an extremely visual way.
Sprint Review
The purpose of the Sprint Review is to demonstrate, and ultimately get acceptance, of all the stories in the Sprint. To set up for this, I pull down all the stories off the Sprint Boards and take them, with my laptop into a meeting room with a projector.
The Product Owners both attend the Sprint Review, and we go through each story and talk a bit about it and then demonstrate it for them to see. The person who has been designated to be responsible for each User Story now demonstrates it to the Product Owners. The Product Owner is usually given the printed User Story for reference during the demonstration, and then signals whether they accept it or not. I keep track of all this and then follow it through in JIRA by closing issues. Failed issues usually go implicitly into the following Sprint, but they're often completed in the same afternoon as the Sprint Review before the next Sprint even really starts properly.
Sprint Retrospective
The final meeting in the Sprint, and the one I personally think is the most interesting, is the retrospective. This meeting is for the team (which includes the Product Owner Assistant, but not any representatives from the client) to discuss how they felt they worked during the last sprint and what they want to change or improve. In the future we may try this with the customer Product Owner included as well for more transparency.
We do this by writing on green and pink Post-It Notes how we felt – green for things we were happy with, and pink for things we weren't so happy with. This is timeboxed to 2 minutes. Then each person gets 2 minutes to go and put their Post-It Notes on a board and talk about what they wrote and explain anything unclear. After that, I group together the pink Post-Its into themes – technical, organisational, communication, etc. Depending on how many themes they are we allocate points to mark which we think are the most important. For example, if there are 4 themes, we might say, each person has 2 points to distribute however they want, and everyone comes and makes marks on the whiteboard next to the themes they want to talk about (yes, you can put all your eggs in one basket). We then pick the theme with the most points (or sometimes the top two), and spend another set of 2 minutes writing (green for constructive) suggestions on how we can improve, and then another 2 minutes for each person to talk about their suggestions.
The retrospectives are framed to be a safe place to honestly discuss how you feel that the team and the project are going. My team is really good at both honestly discussing things we're unhappy with, and finding constructive ways to try and change these things. For example, all the different things we've tried to make the Estimation Meetings more efficient have come out of conversations during the Retrospective. We've also changed times of meetings, workflow items to do with testing and quality, helped our Product Owners write better User Stories and in one case, agreed to “tell the Scrum Master to stfu when she needs to be told” :)
A final note on Meetings. We tend to have Monday as meeting day. This means that Monday morning is spent doing final testing of the User Stories you're responsible for (remember the green arrows!), trying to finish any nicetohaves, and preparing for the Estimation Meeting by reading through the stories in advance. Then after lunch, we have Sprint Review, then Estimation Meeting, Sprint Planning I and if we can, Sprint Planning II. That's usually 4 hours of meeting on Monday afternoon. Tuesday morning we can do the Retrospective before starting work on the next Sprint, and it gives me time on Monday after all the meetings are done, to prepare the board.
The Awesome Things
From the client's perspective, I think having a strict methodology that we adhere to impresses our clients, and because the requirements are described by them in “user terms”, they tend to get a system that works how they expect from the user's perspective, rather than the developer's perspective, which is certainly a typical problem we need to avoid in software development.
I suspect they think we spend too much time in meetings, but in reality they're not paying for some Business Analyst to spend months writing a 400 page specification we can't parse anyway, so this works out well.
Additionally, because we work in Sprints, we can react much faster to changing requirements. In general writing a 400 page specification before a project starts is a procedure that lends itself to being completely unable to adapt quickly. Describing things in User Stories is good, because we only plan the current Sprint out, and the Product Owners are free to change stories and priorities right up to the point where we have the Estimation Meeting and start planning the Sprint.
Scrum says that once the Sprint has started, the Sprint Goals are fixed and can't change. In case of emergency, Scrum tells us that if the Sprint goals must change during the sprint, then we should throw the whole Sprint out and do the Planning again. In reality we had this happen once, but it was only affecting one or two User Stories, so we stopped people working on those until the issue was resolved, and they just worked on other stories in the meantime. I do have to be quite careful about not letting things creep, or Product Owners putting new tasks in to the current Sprint, because that affects the commitment that the team makes during Sprint Planning I. If it's really critical we can usually make an agreement that they can add a new User Story if we remove one with the same number of Story Points, but we should re-get the commitment from the full team if this happens.
I have obviously “drunken the Kool-Aid” when it comes to Scrum. I'm totally convinced that it's awesome. I love the visualisation of all the data, that is in traditional projects, just transparent to Project Management. I think the importance that is placed on empowering the teams to be responsible for how they work and improve is fantastic.
The not-awesome things
There are none! Actually the only not-awesome thing is that I have become completely unable to do anything at all without Post-It Notes! ;) I carry them with me all the time in case I need to brainstorm something.