Java Magazine Logo
Originally published in the May/June 2014 issue of Java Magazine. Subscribe today.

A Sprint in the Life of a Scrum Master

by Régina ten Buggencate and Linda van der Pal

Published May 2014

Saskia Vermeer-Ooms gives a tour of a Scrum sprint.

Most of us have heard of Scrum by now, but not all of us have had a chance to use it yet. And even if you have read books or taken a course, it might be difficult to decide where to start or how to apply Scrum within your own organization.

“That won’t work in our organization” is a phrase you hear often, usually followed by other good reasons why (part of) Scrum will not work. Why not see what someone who has been doing Scrum for a while—someone who has managed to make Scrum work with a Scrum product owner and operations team who live and work in a different country than the rest of the team—has to say?

For those of us who haven’t yet heard, Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. According to Wikipedia, it defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal.”

Régina ten Buggencate and Linda van der Pal sat down with Saskia Vermeer-Ooms to find out what really goes on in a Scrum development team.

ten Buggencate: Hi, Saskia. I heard you’re a Scrum Master now. Can you tell us a little bit about what that’s like? How about starting by telling us about your team?

Vermeer-Ooms: I am the Scrum Master of a development team that consists of three Java developers, one front-end developer, and one team member responsible for making web forms. We work for a UK-based client, and my office is based in the Netherlands. We work with a technology partner who is also based in the UK. This tech partner also does development on the same platform but, more importantly, is also responsible for the operations side of the platform. Any deployments to the live environment must go through this tech partner.

You can imagine that a lot of my time is spent e-mailing, on “chat,” or in remote meetings. My main focus, however, is to facilitate my team reaching the goals we set for each sprint, which is three to four weeks long. We decided not to go for a fixed-length sprint, because most of the time a chunk of work is too large to fit within three weeks, but sometimes a four-week sprint is too long. So, instead we opted to decide on the sprint length when we plan the work for each sprint.

van der Pal: So what does a regular sprint look like? I heard it starts with a sprint planning, right?

Vermeer-Ooms: Sprint planning sessions are usually done on the first Monday of the sprint in a meeting room where we have a big whiteboard that is the same size as the Scrum board we have in our workspace. This whiteboard has plenty of different-colored Post-it notes and a screen that we project the JIRA issues on.

Before we go into the sprint planning session, I make sure that the product backlog is up to date. All issues that were not completed during the previous sprint are moved to the new sprint’s fix version in JIRA. Other issues that have been prioritized by the product owner will have already been labeled under this sprint’s fix version. Team members can also label for this fix version other issues they deem necessary.

I also make sure I have an overview of all the available hours for all team members. Most of my team members also work on other projects, so I use a spreadsheet for keeping track of the available hours per week for team members. I know doing time-based estimation isn’t “Scrum by the books,” but because of the pressure on our team members from other projects, it is a sad necessity.

At the beginning of the planning session, we put the available hours per person on one side of the whiteboard. On the other side, we put on the Post-it notes any JIRA issues that were left over from the previous sprint and any issues we have just added to the backlog.

Then we go through the issues and discuss briefly what each issue is about. If the description is not clear enough for everyone to be able to decide what is required, it is rephrased or sometimes the issue is split into subtasks or multiple new issues (see Figure 1). The main goal of this part of the planning session is to agree on what is being asked of us for each issue and to ensure that the description of what needs to be done is clear. If an issue is not yet on the board, we make a new Post-it note for it.


Figure 1

We have three different colors of Post-it notes (see Figure 2) that correspond to the three different priorities: pink for critical, orange for major, and green for minor. Each note contains the JIRA issue (see Figure 3), a short descriptive title, and the first initial of the team member to whom the issue is assigned.


Figure 2


Figure 3

In the second half of the planning session, we put the issues on the board by priority (highest priority on top). Then each member writes time estimates on their assigned Post-it notes. These estimates need to be agreed upon by the entire team. Everyone has their specialty in the team, but if we need to have a longer discussion about time estimates, we do. We use units of a day, with half a day being the minimum.

When we are done with this, each member adds up the hours for their own issues and writes the total next to the hours of availability that were put on the board at the start of the meeting. We usually end up with more hours than are available, which means we need to reconsider priority. Any issues that don’t fit get moved to the backlog. When we all agree that the issues that are left on the board are feasible, we are done with the planning.

ten Buggencate: So you’re saying that everybody estimates their own issues, but I thought that in Scrum, there was only one role for this kind of work: the Developer role.

Vermeer-Ooms: That’s true, but our team members have other projects, too, and they all have their own specialties. So this is again a point where we deviate from the default laid out by the Scrum method, because this approach works better for us.

Reality Check

I know doing time-based estimation isn’t “Scrum by the books,” but because of the pressure on our team members from other projects, it is a sad necessity.

To finish our sprint planning, at the end of the meeting, I ask each team member to grab their own Post-it notes and take them to the Scrum whiteboard in our workspace, which we use for our daily standup meetings. I also make sure that JIRA is updated; the issues that are left on the board need to be taken out of this sprint version, and I can fill in the time estimates we just agreed on.

Now that the JIRA issues are clear for this sprint, I can create the draft release notes. In these notes, I list all the issues for this sprint and also the dates that are important during this sprint. Because we have a distributed development and operations team, it is important to have these dates agreed on at the beginning of the sprint. We are dependent on our technology partner for deployment of our code to the UAT [User Acceptance Test] environment and the live environment. We have to plan precisely when we need to have our code changes ready in order to make the proposed live deployment date.

This is also the time to ask our tech partner what the current QA Git branch is. Our tech partner also does development on the same platform; therefore, it is essential that we get integration issues out of the way as soon as possible. In other words, it is essential to agree on the current QA branch so that we both have the same starting point.

van der Pal: Wow, that’s quite a lot of work already. So what happens next?

Vermeer-Ooms: What follows are the normal days of work in progress. The day starts with the daily standup meeting in front of the Scrum whiteboard. Each team member informs the team what they were working on yesterday, what they will be working on today, and whether anything is blocking them from making progress.

As shown in Figure 4, we update the board during these standup meetings; Post-it notes are moved from the “To do” column, through the “In progress” and “To test” columns, to the “Done” column. During the daily standup meeting, we adjust any estimates that turn out to be incorrect, and we give an indication of what still needs to be done for each issue in progress.


Figure 4

After the standup meeting, the team gets back to work, and I do my best to resolve any impediments that were mentioned in the meeting.

ten Buggencate: So, do you have any tools to help you with quality assurance? You mentioned you were working with teams in other locations.

Vermeer-Ooms: We have a Jenkins job running a nightly build on any code committed to the current development branch. It also does an automatic deployment of our artifacts to the internal test server. This is very helpful for verifying that ongoing development is not causing other parts of the system to fail. We use this internal test server to verify work in progress and to check functionality.

Unfortunately, we do not have a dedicated tester on our team, which means that we depend on the testing capabilities of all the members of the team. That might be right according to the books, but my experience is that developers don’t have the same mindset that a tester has. We try to make up for this by organizing explicit internal test sessions where the whole team tests a finished feature. We encourage each other to plan internal test sessions as much as possible. These internal test sessions are extremely valuable.

Before we start a session, we list the JIRA issues that need to be verified. We set up a shared Google doc, start testing, and write up all our findings. After the test session is over, I go through the findings and—with the help of the rest of my team—add new issues or move the issues that had made it “To test” but were not resolved back to “In progress.” The issues that were verified to be resolved on our test server are labeled “Passed QA.”

van der Pal: So, now that you have some work that is tested, do you also have the customer test it?

Vermeer-Ooms: Yes; by Friday, we usually have some functionality ready to show the product owner. Therefore, I need to verify with him that the new functionality we are implementing during this sprint is doing what is expected. We write up a short scenario of how we are going to use this new functionality and add a list of questions to get any uncertainties out of the way. After the product owner sends us his answers, we can carry on with the implementation.

ten Buggencate: You have three-to-four-week sprints. When do you stop building new code, and how do you hand over your code to the people who have to deploy it to production?

Vermeer-Ooms: The release date is determined by our client and tech partner; it is usually set on a Thursday. Therefore, I plan one whole week for the deployment cycle by the tech partner and set the Thursday before the release as the code cutoff for our internal integration environment.

This Thursday is the day that we want to have all our code changes in, so they can be run through our integration server, which is a different server from our development test server.

This integration server is running code that is based on the agreed-upon QA branch. Developers can commit and push code to the development branch until lunchtime. After that, the development code is merged with the QA branch and a build is started for deployment on the integration server. Other teams in our office also work on the same platform, so all parallel development comes together on the QA server at this point.

Release branches are named after Pokémon. I hang a printout of the current release branch on our bulletin board (see Figure 5).


Figure 5

We use the Friday before the deployment week for testing on the integration environment and, of course, for fixing any bugs that are found. We can also use this day to do demos of the newly added functionality. These demos are for each other and anyone else from the company who is interested. This is also the day to do a demo with the product owner and verify that we have implemented the functionality correctly. Because the product owner is based in the UK, we have to do his demos remotely. Therefore, sometimes his demo is separate from the other demos.

Say What You Think

Our retrospective meetings are open to others in the company, but it is important that my team members feel safe enough to speak their minds, tell each other their concerns and, of course, give each other compliments.

As shown in Figure 6, if all goes well and we are happy with the results, it’s time for drinks on Friday afternoon. If not, we do drinks anyway. Sometimes we also do a knowledge transfer session where someone shows what they have been working on lately.


Figure 6

After the weekend, we start our deployment week. Monday afternoon is the code cutoff for the deployment to the UAT environment. The team has until 3 p.m. to fix any bugs and retest. I recheck the release notes at this time to see whether all the issues listed have, in fact, been covered by this sprint and will make the deployment.

The deployment instructions involve a list of artifacts that need to be deployed as well as any additional instructions, forms, or workflow files that need to be uploaded to the portal manually. The instructions also include any manual configuration steps.

On Tuesday morning, our tech partner deploys our code to the UAT environment. When UAT is signed off by the product owner, the code is deployed to the Clones environment (which is a second acceptance environment that contains an exact copy of live data from the production server) on Wednesday. On the Clones environment we test to verify that the live data will not be affected by our changes and to see whether the added functionality is doing what it should do with the actual data.

van der Pal: So what happens if you are testing on the Clones environment and something doesn’t work as expected?

Vermeer-Ooms: When our testing finds a major bug, the bug should be fixed as soon as possible. We then exchange e-mail with the tech partner to agree on a new deployment date as soon as possible.

After the new deployment is done, we retest and repeat the process if more fixes are needed. Sprints such as this necessitate a lot of flexibility from our tech partner, and we are lucky that they are usually very helpful in getting done what we need.

ten Buggencate: Now that everything is done, do you also have a sprint review to see what you can do better next time?

Vermeer-Ooms: Because the deployment to the live environment is on Thursday evening, I often plan to have the sprint retrospective meeting on this day. In most cases, there is not much left to do for the sprint, which means it is a good time for us to reflect on what went well during the sprint and what can be improved for future sprints.

Our retrospective meetings are open to others in the company, but it is important that my team members feel safe enough to speak their minds, tell each other their concerns and, of course, give each other compliments (see Figure 7).


Figure 7

I ask each member of the team to prepare for this meeting by writing down the good stuff and the bad stuff they encountered during this sprint. Before the meeting, I prepare a shared Google doc where they can write these points under their name. I also list the actions that came out of the previous retrospective meeting, so they can see which actions have and have not been accomplished. We start the meeting with a round of bad stuff. Everybody is free to speak their mind as I take additional notes in the shared doc. When everybody has had their turn, we go through the items again and write down an action list in order to improve our way of working.

When everybody feels that their points have been heard, we do the same thing to discuss the good stuff. I make sure all comments are written down in the shared doc, because these are always nice to read later. Sometimes we also do a team demo during this meeting so everyone keeps up to date with the latest additions to the functionality of our product. Sometimes team members present what they have already been doing for the next sprint, or we discuss some of the technical discoveries that were made during the sprint. At the end of the demos, we always applaud.

If final testing of the Clones environment in the afternoon gives us the expected results, we give the go-ahead for the deployment to the live environment that night. After 6 p.m. the holding pages of the live site go up to show end users that the platform is undergoing maintenance. Deployment is done, and then we get the signal that we can go in to verify that the deployment was successful. If everything went OK, we are happy to take down the holding pages, because the sprint made it successfully to production.

Learn More

 The Scrum Guide

van der Pal: But this is only Thursday evening; what do you do with Friday?

Vermeer-Ooms: Next Monday we will be doing sprint planning for the next sprint, so I use Friday to get everything cleaned up and organized again. I go through all the JIRA issues that were planned for this sprint to see whether they have been reassigned and set to the correct status (resolved). There are always some issues that were not completely resolved during the sprint, so these need to be moved to the next sprint so they will be open for discussion during the upcoming sprint planning session. I put the actions that came from the retrospective meeting on a Post-it note on the Scrum board so it is clear that they also are tasks to be done.

Sometimes I decide that the Scrum board needs some cleaning up. Any Post-it notes still hanging are taken down, and I redo the lines on the board. I like straight lines.

Friday is also a day that team members spend on their other projects, clean up their environments, take on the actions from the retrospective meeting, or take on a task that will improve the quality of our code or improve our process. If they have nothing to do (which has never happened), they can help me prepare for the next sprint planning.

ten Buggencate: Wow—so that’s what a whole sprint looks like outside of a training room. Thank you for sharing!


Saskia Vermeer-Ooms
is a senior software engineer at Worth IT. She helps organize the Dutch Devoxx4Kids edition.


Régina ten Bruggencate
is a senior developer at iProfs who is active in Duchess and Women in Java.


Linda van der Pal
is a developer at iProfs and the founder of Duchess, and is involved in Devoxx4Kids.