Stuffing Envelopes: The Power of Small Batches

Working in small batches in a Lean principle. That's counter-intuitive for many people. The idea that large batches are more efficient is deeply ingrained in modern day society. Doesn't overhead increase when working with small batches?

Here is a group exercise to demonstrate the power of small batches.

Each participant receives the following materials:
* six letter sized papers
* six envelopes
* a pen

Also, there's a list of six names which everyone can see.

Each participant has to write a name from the list on a piece of paper, fold it, put it in the envelope, seal the envelope, and finally write the name on the envelope.

They should do this for all six names on the list.

Divide the participants into two groups. The participants in one group follow the Large Batch Method. Participants in the other group follow the Small Batch Method.

Each participant of the Large Batch Method first has to write all six names on the six envelopes, then fold all six papers, then put the papers into the envelopes, then seal all envelopes, and finally write the names on them. For many people, this way of working intuitively seems the most efficient.

Each participant of the Small Batch Method group writes a name on a piece of paper, folds it, puts it in an envelope, seals the envelope and writes the name on it. Then does the same for the next name on the list.

I also ask the participants to secretly estimate how long they think it will take them to complete this exercise.

Every time I have done this exercise a participant of the Small Batch Method is the fastest. On average the Small Batch Method is about 20% faster. This never fails to surprise people.

Also, most people tend to underestimate the time they need to complete this exercise, sometimes by as much as 100%.

Obviously there are parallels with software development. The following are some of the observations that are typically made:

* Small Batch Method participants eventually settle into a rhythm. The Large Batch Method people will often get stressed out at the end in a mad dash to get things finished. In software development people can get very stressed in the last few weeks of a Big Bang release, whereas if the software is being built and rolled out incrementally, doing a release is just business as usual.

* What if it turned out that the folded papers didn't fit into the envelopes and needed an extra fold? The Small Batch people would have found this out sooner in the process than the Large Batch people. In software development it makes sense to deliver so called "Tracer Bullets" early in the process to find any technical bottlenecks, problems with usability, "wrong" requirements, and so on.

* The first finished envelope (value for customer) was delivered far sooner by the Small Batch Method. In software development a product that includes only a couple of useful features of the complete intended scope can still deliver value. Why wait with releasing useful software until "everything" is "finished"?

* The order of the envelopes might get messed up with the Large Batch Method. The wrong name might get written on an envelope, resulting in a wrongly addressed, and unhappy, customer. In software development doing a huge release with many features will risk having more bugs, as there are more things to test and integrate and keep track of. If something goes wrong during a release to production it will be significantly harder to track down what caused the bug than it is with a smaller release.

* Apparently, we can be way off estimating how long something as simple as stuffing envelopes will take. But we will probably be more accurate the second time we have to estimate our work. The problem in software development is that we never estimate the exact same thing. The requirements are never exactly the same, the domain is different, the technology is different and there may be different people working on the software.

This exercise was inspired by a video by Ron Pereira. In this video Ron demonstrates an even simpler version of this exercise, with ten envelopes. Study has shown that the Large Batch Method loses time mostly by "housekeeping" stuff like keeping the stacks tidy, shuffling papers around the table, etc.

Eric Ries also has an excellent article on Small Batches, which I came across while doing research for this article. It nicely sums up all the advantages of Small Batches.

The first time I tried this exercise I used ten envelopes per person, but then the exercise took a little too long. With six envelopes it is a bit shorter and it gets the point across just as well.

If you have a larger group, you might want to try this with teams of two or three people working together. The Small Batch people would work as individuals, the Large Batch people would work as an assembly line. Give each group 20 seconds before the exercise to discuss how to divide up the work. You probably want to use ten or twelve envelopes when doing this exercise with groups, otherwise it is a bit too quick.

Now go forth and use the power of small batches!

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.

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!