Our Scrum heartbeat

In Scrum every sprint has the same length and the same set of ceremonies. This regular cadence forms the heartbeat of the team.

Our very first sprint was three weeks, but that felt a bit too long. So we made our  second sprint two weeks long. It has remained so ever since. We have toyed with the idea of changing it to one week sprints, but the need was never there to really try it out.

Our sprint starts with the Sprint Planning on Wednesday morning 10:00. It is timeboxed to two hours. In the early days we really needed those two full hours, and I sometimes had to cut the meeting short. Since we are doing backlog refinement more regularly, our Sprint Planning usually doesn't take much longer than a single hour.

Backlog refinement takes place on Mondays 11:30 and takes one hour. There's also a refinement session on Wednesdays 11:30 in the weeks when there's no Sprint Planning. By planning it right before lunch we make sure we keep it to one hour, because by 12:30 everybody wants to go to lunch.

Sometimes we skip these refinement sessions if there's nothing to refine. Sometimes we have an impromptu refinement session if there's a sudden burst of work coming in. All in all, this has proven enough refinement for us to make the Sprint Planning go smoothly.

We have the Sprint Review on Tuesdays at 16:00 and the Sprint Retrospective the next day, Wednesday, at 09:00, before the Sprint Planning. We used to have the Sprint Review at 14:30 and the Retrospective at 16:00. Moving the Sprint Review to the end of the day gave us more time to finish some final stories and prepare for the demo.

Also, at the end of the day we could sometimes be tired and cranky, especially if the Review didn't go so well. That would have a negative effect on the Retrospective. By moving the Retrospective to the next day's morning, everybody would be refreshed by (hopefully) a good night's sleep. This had a positive effect on the Retrospective.

In a sense our Retrospective has become the start of a new Sprint, rather than the end of the old one. By having the Sprint Planning right after the Retrospective, the ideas that are formed during the Retrospective are still fresh in our mind when we set out to plan the next Sprint.

So, that is our Scrum heartbeat. For us this has worked very well. I'm very interested in what your team's Scrum schedule looks like. Feel free to leave a comment!

Face-to-face conversation versus documentation

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. That's one of the Agile principles. For someone coming from a traditional software development background, where detailed written requirements are the norm, replacing documents by conversation may seem... I don't know, "ineffective" maybe?

Let me show why a face-to-face conversation results in better understood specifications more quickly through an analogy in a field I am familiar with.

I love to play board games with a group of friends. Not the well known ones like Risk and Monopoly, but "gamer" games, such as Puerto Rico, Princes of Florence and Taj Mahal. Every once in while my group likes try out a new game, one none of us has ever played before.

So, how do you learn a brand new game?

I don't know if you have ever tried to learn a board game simply by reading the rulebook, but that's actually pretty hard. I know, because I have done it many times, because there was no one around to teach us.

Even games that aren't actually that complex, that have rulebooks that are as well written as they can be, with pretty pictures and easy-to-follow examples, are still a pain to learn by reading the rulebook.

It's much easier and quicker, and a lot more fun, to learn a board game when someone explains it you face-to-face. A game of medium complexity may take fifteen minutes to explain. That same game might take over an hour to understand when trying to learn it through the rulebook.

Even after thoroughly going through the rulebook we would always miss "that one rule" and only catch it halfway during our first game, or even after many games. Having a live teacher makes it less likely that you miss an important rule. A teacher can watch on while you play and correct a misunderstood rule right away. That's the equivalent of having a Product Owner around reviewing your work as soon as it is done. You catch misunderstood requirements much earlier in the process.

Learning a board game is like understanding software requirements. It's much easier to understand what a customer wants when you have a face-to-face conversation with him. You will have less misunderstandings and it will also be a lot faster than communicating through written documentation.

If someone ever challenges you about the use of face-to-face conversations to specify user needs, rather than detailed documentation, ask them whether they would prefer to learns a new board game by reading the rulebook or having someone explain it to them.

There are more instances where a conversation is more effective than documentation (describing a bug for example) but I'll leave that for another post.

Scrum and Fixed Price contracts

"Should we offer to do this project Scrum or fixed price?". That's a question I've actually heard when discussing a bid on a new project.

That question is wrong in many ways.

Fixed price is a type of contract. When people say fixed price they often mean fixed price and fixed scope.

Scrum is a framework for developing complex products. It's not a contract type. The Scrum Guide does not even mention contract types.

Comparing Scrum with fixed price is like comparing the genre of a book with the word processor it was written with. "Is this a thriller or an Adobe PageMaker book?".

See? That makes no sense at all.

There's a risk for the vendor in fixing both price and scope at the start of a project. Most software development projects are exploratory in nature. There are many unknown variables at the start of a project. If the vendor was off with their estimate they might lose money on it.

There's a risk in fixing the scope for the client too, although they often don't realise it. They might get exactly what they asked for, but discover, as the project progresses, what they asked for is not what they actually needed!

Scrum and fixed-price-fixed-scope contracts are often seen as opposing entities. The power of the Inspect & Adapt cycle of Scrum is weakened when the scope of the project is fixed. You could still inspect the product increment at the end of every Sprint during the Sprint Review, but how do you adapt to new insights when you can't change the scope?



The vendor could allow the client to swap obsolete product backlog items for new product backlog items that are similar in size. That's great for the client, but it doesn't do anything to mitigate the risk on the vendor side. If the vendor underestimated the project, they still have to do the same amount of work.

No matter the chosen project management methodology or product development framework, be it PRINCE2 or Scrum or whatever, a fixed-price-fixed-scope contract will be a cause of headaches in the context of software development. The quality of the resulting product may suffer, leaving all parties unhappy.

Are there contract types that work better when developing software? I'll talk about that in a next post. Meanwhile, I'd love to hear about your experiences with Scrum and working Agile in a fixed-price-fixed-scope situation.

The Perfect User Story

When our company decided to implement Scrum, I suggested to our Product Owner that we express our customer requirement as User Stories.

I assume most of you know what a User Story is, but for those few that don't - a User Story is a sentence specifying a user's need. The typical format is: "As a <user type> I want to <do something>, so that I can <reason>".

Our Product Owner was new to Scrum and hadn't used User Stories before. We had a discussion about the pros and cons of User Stories. One particular discussion was about the following User Story: "As a website visitor I want to view advertisements, so that I can go to external content I am interested in".

However, we argued, a website visitor typically isn't interested in viewing advertisements, she prefers the website without them. We rewrote the User Story: "As the website owner I want to show advertisements on my website, so that I can make money". That sounded more honest, as it's the owner of the website that wants something. It still felt a little weak, though, because the website owner isn't the primary actor here. The website owner doesn't actually DO anything in this scenario.

According to you, what is the best User Story?

I'm giving you some space to think about that before I give the answer.

Well?

The answer is: it doesn't matter!

The goal of a User Story is to start a conversation between the Product Owner and the team. It's the shared understanding that follows from the conversation that matters, not the actual wording of the User Story.

This doesn't mean that poorly written User Stories are fine. A well written User Story helps toward gaining a shared understanding. But they aren't the goal. The goal is creating a beautiful product and delighting the customer. So keep that in mind next time you have a discussion about the "perfect" User Story.

Hi there!

Hi, and welcome to my blog!

My name is René Wiersma. I'm a consultant, developer, tester and Scrum Master for an Agile team at New Nexus Mobile, in Tynaarlo, the Netherlands.

Right now it's pretty empty around here, but I'm planning to fill this blog by sharing my experiences with Scrum, XP, Agile and Lean practices from the actual nitty, gritty world of software development.

Check back soon!