Presentation: Scrum at bbv Software Services AG

This is a presentation I hold in 2010 for bbv Software Services AG. It shows how my team lives Scrum.

I’d be glad to see your feedback in the comments section…

Amongst many reasons we do Scrum for, these are the two main ones:

• deliver business value as quickly as possible
• do this in the best possible quality (see Code Quality! Building code you wont curse tomorrow for information how we achieve quality)

If you do not have a vision, how do you decide then?

The vision helps us in decisions every day:

• is this feature really needed?
• is a TextBox good enough, or is a auto-completion search box needed?

We do Scrum to be able to follow the changes in the business of our customers. The vision is the only stable goal. Therefore, the vision helps to get some stability into the project.

We are developers, and therefore, we like tools.

There is one tool, that is most important for us because we use it every day, all the time.

We use this tool to keep track what we need to do, to communicate with each other and to feel great when we tear them apart:

Index cards.

We even have a pure index card based product backlog. We do not need an electronically tool because my team is co-located.

Okay, our project has to fulfill a lot of regulatory stuff, and we need to keep track of everything electronically – but let’s focus on what is needed so that we can work. The rest are just artifacts produced for the project output.

Then let’s have a look at our product backlog:

This backlog contains only the user stories needed for the next release. Therefore, the number of cards is small enough to handle them manually.

But how do we get to this set of user story cards?

There is only a project if there is a business need. This need defines a set of features. A feature is a high level description of a functionality a user can perform, e.g. “the system has billing functionality”.

These features can then be broken down into epics: who performs which operation to accomplish what. We use epics to determine the scope of the next release. Epics must have a size so that we can prioritize and roughly estimate them.

After selecting the epics for the next release, we break them down into user stories. User stories have a size that allows us to work efficiently. We try to get about 10 stories done in a two week sprint.

Finally, we estimate these user stories to get a release plan including milestones like feature-complete and release-candidates.

The result is the product backlog with prioritized and estimated user stories.

It is important to say that this product backlog in its initial state will…

… change.

We develop software both incrementally and iteratively.

Incremental means, building software feature by feature. Always a complete part at one.

Iterative means, building a first version of the software, get feedback on it and then improve the next version. Until the software is finalized.

When you combine both, software is built feature by feature (or user story by user story), get feedback on it and improve. It is important that a feature is always something complete. Something a real user can give feedback on. (see From user stories to architecture for more information).

The user feedback is then fed back into the product backlog.

Now it’s time, to get started with the sprint.

In our planning meeting, the product owner explains the user stories he would like the team to implement in this sprint. My team asks questions until we are confident that we know what has to be built. Note that there are still plenty of unanswered details but they will get clearer once we started building a solution. It is important that the whole team is present so that everyone knows on what to focus in this sprint.

Let’s take a look a typical user story:

Each user story has a text that helps us to remind what is to be built. But more important is the discussion the team has about this story.

In the bottom right corner, you can see our estimate of 5 story points for this story.

In the top right corner, we add additional information about the product this story belongs to. We need this because our team works on several products at once. These products are strongly related – otherwise it would not make sense to multitask within a single team – but have different release cycles. In this sample the “2.1” stands for the application core in version 2.1.

The number in the top right corner is some kind of identifier. It is however important to know that we do never reference this story by this number when we talk about requirements. This number is just needed for administrative work. The first two digits of the number is the sprint in which the story was added to the product backlog.

Sometimes, we add a story title to the card for referencing in discussions. This could be “counters” for this story.

Cards have two sides. On the backside we add…

… acceptance criteria for the user story.

In this example, the story is considered done when the “counters data” is stored when a “run” is completed and this data contains barcodes, start- and end-times and a status.

While this probably doesn’t mean much to you, it is enough for the team to understand what to do. The knowledge needed to understand this requirements is provided by the product owner and stored inside the heads of the team-members.

For larger stories, we write tasks:

These tasks are used to facilitate estimating and team work.

Larger stories tend to be harder to estimate than smaller ones. This is normally because it is much harder to think of everything that is needed to fulfill the story. Therefore it helps to define tasks. Every team member gives input so that hopefully nothing is missed.

Furthermore, tasks are used during implementation to communicate who is doing what. You can see on these cards that there are names written on them. When a developer start working on a task then she or he writer her or his name on the card and moves the card into the “work in progress” column on the story board – I’ll show you our story board two slides from here. Tasks are changed very often. You can see on the card on the top left that I added some information after starting working on this task. I needed to ask our product owner some question about the current implementation. All these TODOs are tracked on the task cards.

Let’s go back to the planning meeting. Here you can see the result of the planning meeting:

A prioritized sprint backlog consisting of user stories with acceptance criteria and if needed associated tasks. Note that you cannot see the task cards because they are underneath the story cards.

This story backlog is the moved on to the story board:

This picture was taken one day into the sprint.

You can see the stories of the sprint backlog in the column called “Stories”.

In the leftmost column you can see the sprint goals, followed by the sprint burndown chart, a list of the responsible for the demonstration in the sprint review, a matrix to track the time spent pair-programming and information about absences of team members.

The tasks that are still to do are in the “Tasks to do” column and are moved to the “WIP” work in progress column and back whenever a team member starts or stops working on a task. It is even possible that new tasks are create and added when we discover them during implementation.

When all tasks of a story a done then we move the story to the column “Verify”. Verify means three different things for us:

• Story review
• Verification by testers
• Verification by product owner

Before the story is passed to either testing or product owner. All developers that took part in implementing the story stand together and review the story:

• acceptance criteria fulfilled?
• acceptance tests written?
• release notes written?
• are there further actions to take like adding follow-up user stories to the product backlog?

Afterwards, the user story is tested and shown to the product owner. The product owner verifies whether the team had understood correctly or whether the story is rejected and further tasks have to be done.

If all three verification steps are taken then the story is considered done.

Underneath the done column you can see the

• “definition of done” – a checklist when you are allowed to commit code to the source repository, when a story is done and when we consider a product increment as a release candidate.
• parked items – things that we cannot do at the moment because of whatever reason (give them a place so everyone can see them!)
• “funky Friday tasks” – things we should do but can wait until the end of the sprint when everyone has some slack time. For example upgrading developer tools.

This is our team room.

As you can see, we work as co-located as possible. Every team member is in discussion distance. If someone has to say something that is important to everyone he or she can simply stand up and say so.

On the right, you can see two team members pair programming.

We like to visualize all important information.

Here you see the wall that is in the back of the two pair-programmers from the picture before.

Now, let’s see how we transform a user story into working, maintainable high-quality software:

We start with the user story and its acceptance criteria.

These acceptance criteria are transformed into acceptance tests or executable specifications (whatever term you like more). When these tests run successfully then we know that the story is implemented correctly (okay – we know that for 95% but this is a different presentation).

These acceptance tests drive our Test Driven Development cycles. They provide the environment for our unit tests.

Finally, all these automatic tests give us the stability we need in a project with quickly changing requirements. They define the current state of the software.

In addition to the meetings defined by Scrum, Planning, Daily Scrum, Sprint Review and Sprint Retrospective, we hold three meetings per Sprint that help us find a common understanding in our team.

The first meeting helps us to get a team wide understanding of technical aspects of the project:

The main topic of the architecture workshop is to build team-wide common knowledge needed to implement the User Stories (and other Backlog Items) of the current Sprint. Note that the team will come up with questions in the Sprint planning meeting while discussing the break-down of stories into tasks.

This meeting also helps to have equally distributed know-how of the architecture; resulting in better designs in each developer’s daily work.

Finally, the team may come up with architectural problems that were identified in previous Sprints. Either the team can solve them in this meeting or a team member takes responsibility for actions during the Sprint (normally the architect, but can be anyone on the team).

The second meeting helps us grooming the product backlog and push the understanding of the domain we solve with the project. We call this meeting…

… pre-planning meeting.

The team discusses about the current state of the product backlog:

• are there missing user stories?
• are there user stories that should be broker down into smaller ones?
• are there blocking issues that prevent user stories from being implemented?
• are there risks to the project and how are they mitigated?
• what is the current state of the release planning?

The third meeting helps us improve our technical skills and to get a single style how software is developed across all developers. We learn this in the …

… Coding Dojo.

In a coding dojo, the team (or a group of developers) sit together in front of a beamer showing what happens on a computer while two developers practice pair programming. The members “watching” can provide inputs to the developing pair.

A coding dojo normally takes 1 to 2 hours.

Coding Dojos push common understanding and common behavior. Therefore, they are a perfect environment for a team to learn as a whole.

But we do a lot more to improve our skills. This is an overview:

See https://www.planetgeek.ch/2010/11/23/learn-as-a-team/ for more details.

At the end of each Sprint, we invite our stakeholders for the …

… Sprint Review.

Our product owner informs the stakeholders about the current state of the project, what we did and what comes in the future.

On the left, you can see the story board with the done user stories, which are then presented in the …

… demonstration.

We show the newly implemented features to the stakeholders and discuss questions and feedback.

As you can see we show these features on a test environment that matches the production environment as much as possible. This minimizes surprises when deploying to a real production environment.

After the Sprint Review, we take some time to celebrate and talk with all involved people in a relaxed atmosphere.

To complete the Sprint, we hold a …

… retrospective. In this meeting, all team members look back at the Sprint and we gather data about was good, what can be improved, what should never happen again and other ideas:

In a typical retrospective, we gather this information on a white board with cards.

Then, we discuss the improvements and ideas and define actions for the next Sprint.

We visualize the progress of these actions on a …

… Kanban board. This is a very transparent way of showing how the teams improves.

After the first version of our product went live, we discovered that it is hard to plan for the effort needed for maintenance and support. Therefore, one action out of a retrospective was to introduce …

… a maintenance and support Kanban board and that we reserve a fixed amount of time for these activities.

When I took this picture, we reserved 40 hours for this kind of work.

Now if an issue arises, our product owner can hang it in the “selected” column and the team works with highest priority on this issue.

When we do not need the full time-box reserved then we can work on the stories on the story board and we simply will deliver more than committed. When we reach the time-box reserved, then we either have to abort the Sprint because the issues are more important than new stories, or we work only on stories to hold the sprint commitment. This decision is up to the product owner. But he has to decide!

When I look back at more than three years of developing software in an Agile way and with Scrum then these are my conclusions:

There is much more needed than Scrum alone. For example, when you do not invest in engineering skills like Test Driven Development or Continuous Integration, then you will have a process that can adapt to changes in customer requirements, but what about your software? Is your code “agile” enough to follow Scrum? Or do you hear “we cannot change this because it is too complicated and will cost too much” all the time?

Although Scrum does not define many things. It is hard to live Scrum from developers up to management and customers.

It is very hard to get all involved participants to learn to think “Agile”.

When I had to summaries all advantages of Scrum into a single sentence then it would be …

… that we can build software faster and in better quality.

This sounds contradictory at first glance, but never underestimate what a focused and motivated team with the right tools and practices can do in very little time.

From a pure developers point of view, I have to add that Scrum helps a lot in reducing stress.

When practicing Scrum then you plan and work based on measured hard facts and not on a release date defined by someone up in the hierarchy.

Finally, working with Scrum, in a highly motivated, self-organized team is simply …

… more fun.

Thanks for reading!

I’d like to read your feedback in the comments section.