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.