Estimate Using Story Points

Imagine you are standing in front of a pile of bricks. Your job is to estimate how long it will take to make neat 3x3 stacks of these bricks. Sounds easy, right? But if you think about it there are quite a few variables involved and assumptions you have to make.

The bricks you can see, on the outside of the pile, all look fairly similar shaped, but perhaps there are some awkwardly shaped stones in the middle of the pile that you can't see which would make the work take longer.

Variables and assumptions

If the work is done outdoors, the weather could be an influence. If it is a hot day, or a rainy one, that could make the work take longer. Or perhaps the work is to be done at night. Is there any lighting you can use then? What about other tools? Who will perform this work? Will it be a single person, or a team? Are they experienced in this type of work? If it's a team, have they worked together before on a similar job? Are they in good shape, do they have the stamina to perform this kind of physical duty?

If you have never estimated this kind of work before, your first estimate will likely be a very rough guess with a lot of padding on both sides. If you have done this before, you can probably make a better estimate.

Estimating software

Estimating software is much like this. There are often many unknowns and it is hard to come up with a good estimate. This is where story points come in.

Suppose there are multiple piles of bricks that have to be stacked. While you still don't know how much time each single pile will take to stack, you can assign a number of "story points" to each one. You could assign one point to the smallest pile of stones, two points to each pile that looks about twice the size of the smallest one, etcetera. You are sizing the chunks of work relatively to each other.

Then, you would do the work on the most important, most valuable, pile of bricks and measure the time it takes to perform the job. Suppose you estimated your first pile as two story points and it took you eight hours. If the total number of story points of the remaining pile is, for example, ten story points, it would mean it might take roughly another forty hours to stack all the remaining piles of bricks.

However, don't stop there. Every time a pile of bricks is finished, update the measurement to get a more precise estimate on when it will be done. This is called velocity.



Velocity

In Scrum, at the end of each sprint the number of story points for finished stories is counted. Over time this will give a decent indication of how much work can be performed during a sprint. Usually it will take three or four sprints for the velocity to become meaningful. This can then be used to estimate how long the remainder of a release or project will approximately take.

Even when using story points you cannot perfectly predict beforehand how long a release or project will take. However, it will allow you to adjust your plans during the release or project based on actual data, rather than on wishful thinking.

Sprint length

If you are the Scrum Master for a new team, one of the first things you have to figure out is the sprint length. As with many things, my advice would be: take it to the team!

Set up a meeting with the whole team to determine the sprint length. This doesn't have to be an hours long meeting, just a quick check up on what everybody thinks.

Remember though, that the Scrum Master is the one ultimately responsible for choosing the sprint length. Sometimes teams choose a sprint length that is too long. If you think this is the case then go for a shorter length.

If you are really clueless about the sprint length, try two weeks. That works for a lot of teams around the world.

At the end of the sprint use the retrospective to discuss how the chosen sprint length worked out. Inspect and, if necessary, adapt!

Timebox

The sprint is a timebox. Once you start a sprint, do not change the sprint length. If you run out of work before the sprint ends, add more work. The Product Owner decides on the priority on items to work, the team decides how much extra work they can fit into the sprint.

Make use of burndown charts and work with small user stories so that you may see early in the sprint that possibly not all of the planned work can be achieved. If it turns out you have planned for too much work in the sprint, use this as an opportunity to inspect and adapt. The team should decide what they think they can still finish in this sprint. The Product Owner decides what is most important. Use the Sprint Goal to guide these decisions.

Organisation

If the length of a sprint is decided at the organisational level, I would try and find out what the reasons behind it are. Imposing the length of the sprint on the team hampers the team's ability to self-organize and I would view this as a possible impediment. There might be good reasons for it though, such as avoiding overlapping meetings with other teams, or synchronizing release schedules.

Steady rhythm

Don't change your sprint length based on the amount of work. So, don't have one sprint be three weeks, the next one four weeks, the one after that two weeks, etc. The amount of work should be chosen based on the sprint length, not the other way around. Ideally, you want the sprint length to be the same for every sprint. This allows the team to settle into a steady rhythm.

Having the same length, sprint after sprint, makes things more predictable. Team members and stakeholders, will know when each Scrum meeting is without having to check their appointments. Also, it will be easier to determine velocity if the sprint length is the same every time which makes planning releases easier.

Our sprint length

Our very first sprint was three weeks long. That felt a little long to us, so we changed it to two weeks for the next sprint and it has been so ever since. We discussed changing it to one week sprints a few times, but so far, two weeks still works best for us.

How long are your sprints, and how does that work for you?

Our Kanban board

We are a colocated team. Our Kanban board is in our team room in view of everybody. It's a great tool for collaboration and promoting transparency. We keep a virtual copy of our board in Jira up-to-date which our customers may use to view progress. Our Kanban board, and the process it reflects, has gone through quite a few changes since we started our Agile journey.

At first, our board was simply divided into three columns: To Do, Doing and Done. We used to fill the To Do column at the start of a sprint with stickies containing User Stories and accompanying tasks. The tasks were defined during the sprint planning. Later we found it easier and quicker to define the tasks while in front of our physical board rather than in the meeting room.

We quit estimating tasks long ago. Our stories are small enough to be able to see progress during the sprint. Our progress is drawn on a burn down chart. Most of our user stories are around three story points in size. We do about fifteen of them during our two week sprints. Usually one or two stories will be finished per day.

We had a Review column for a while. Stories in that column had to be reviewed by the Product Owner before they could be marked as "Done". We introduced this column because too often our Product Owner would not be satisfied with a story during the Sprint Review. The Review column forced us to evaluate a story with the PO much sooner. Eventually, the quality of our work rose and we decided we could do without this column.

We added a To Deliver column to make visible which stories are ready for delivery to a  test or production environment. Recently we upgraded our Definition of Done, and now every story has to be delivered to a test environment to be considered "Done", creating a continuous delivery flow.

The testing task can and should start before the development of a story is complete. However, it made sense to our team to have a Test column. A story in that column is delivered to our development environment and is ready to be tested by whomever is available at that moment to perform the testing task.

The most recent addition to our board is the Prepared column. Stories in this column have been are OK-ed by both the team and our customer. These stories have an estimate and are ready to be developed. We don't plan a sprint in advance anymore. Instead we pull the top Prepared item from the backlog as soon as we finish an item. In effect, this makes our process currently more Kanban than Scrum.

Every column on our board has a maximum number of allowed stories, another Kanban influence. This forces team members to focus on finishing work, rather than starting new work, and it promotes collaborating on items to get them done.

And there you have it, the current state of our board!

Agile feedback loops

Ask ten agilists what Agile is all about, and likely you'll get ten different answers.

I would say Agile is all about feedback. Other Agile processes, practices and principles follow from the Inspect & Adapt cycle.

Arrange, Act, Assert

If you are familiar with writing unit tests you probably know the Arrange, Act and Assert pattern. Sometimes it's called Setup, Execute and Validate. It amounts to the same thing, but AAA is a nicer acronym, isn't it?

A unit test is a small piece of code that tests a single assumption. The first thing a unit test does is setting up the data and objects in such a way that it can perform the test. This is the Arrange part. Then it executes the actual function you want to test. This is the Act part of the pattern. Finally, the it checks whether the result is what you expected, which is the Assert part of the AAA pattern.

Unit tests validate the functionality of the software at a microlevel. There are many more such patterns to be found.

 Acceptance Criteria

For example, a user story usually comes with a set of acceptance criteria. When the story is reviewed by the customer she will check whether the story meets these criteria. In a sense, the user story and the accompanying acceptance criteria are the Arrange part, the actual building of the functionality is the Act part, and the customer review is the Assert part.

Scrum facilitates this kind of review by prescribing the Sprint Review meeting, where the goal is to gather feedback on the product increment from stakeholders, such as customers and users.

Retrospective

Another Scrum meeting that facilitates the Inspect & Adapt cycle is the Sprint Retrospective. Here the process is inspected rather than the product, but the principle is the same. At the Sprint Retrospective plans for improvement are made that are carried out in the next sprint. At the next Retrospective it is checked how these improvements have worked out. This may lead to new improvement plans, and this cycle is repeated over and over.

Plan-Do-Check-Act

The Plan-Do-Check-Act cycle was made popular by Dr. W. Edwards Deming in the 1950s. Originally used in manufacturing, it is another example of the Inspect & Adapt cycle. During the Plan phase the output expectations are established. Then this plan is executed and the product is made during the Do phase. It is checked whether the results match the expectations. Appropriate actions are taken in the Act phase, and this cycle is also repeated.

Lean Startup

A variant of the PDCA cycle is called Hypothesis, Experiment, Evaluation, which is used in the Lean Startup method, made popular by Eric Ries. First, a business hypothesis is formulated. Then, as quickly and as cheaply as possible, this hypothesis is implemented and evaluated. If the outcomes are not as expected a business "pivot" may be needed, steering the company in another direction, and the underlying assumptions may be adjusted. Of course, this is then again subject to the same cycle, over and over again.

As you can see, there are many feedback loops at many different levels. Combine some or all of them to continuously improve your processes, products, services and businesses.

I'm sure there are many more examples of feedback loops. Feel free to leave a comment to let me know which ones I missed.

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.