We started the development with the following SCRUM configuration:

• Iterations of 4 weeks.
• The Release Backlog is composed of user stories which are estimated in story points.
• The Iteration Backlogs are composed of the selected user stories for the iteration, which are decomposed into tasks, that are estimated in hours.

This approach is supported by several books, including the original Scrum book and the superb Mike Cohn’s Agile Estimating and Planning book. The original Scrum proposal recommends 4 weeks as the duration of each sprint (iteration). Regarding to the backlog contents, the original proposal talks about features as the main item for the product backlog, and tasks for the iteration backlog. Features would be estimated in days and tasks in hours.

Mike Cohn elaborated on this proposing to use user stories as the main product backlog artifact, and tasks for the iteration backlog. He proposes to estimate user stories with ideal days or story points, and tasks in hours. It is worth to notice that the user stories technique was popularized by Kent Beck in his seminar Extreme Programming Explained book. In the first edition of the book, Kent Beck proposed to estimate the size of stories with points (1,2 or 3). But in the second edition he advocates for using real time estimates. In the same way, he proposes splitting stories into tasks and says that developers should estimate them, although many XP practitioners prefer not to estimate tasks at all, or even to create stories as small as possible in order to eliminate the need for separate tasks.

After several weeks applying the mentioned approach, I realized that there were some aspects I didn’t like in our planning strategy. The process of splitting stories into tasks and, specially, the estimation of each task was a high time-consuming activity for the project and added little value. I think that this activity was becoming what Lean people call waste:

• Foreseeing estimations at the task level is, by definition, very inaccurate. It is not worth to think thoroughly about how many hours are you going to spend in implementing some subsystem and its tests. Specially if you do it one, two or three weeks before you do it. You’ll be wrong, because software development is a wicked problem.

• If you are going to manage inaccurate estimations at the task level, you have added no value to the story point estimations you already have. These can be converted into real time easily using your team speed so, why bother in the extra-effort?.

• In order to determine the tasks that need to be done for implementing a story, there are two contradictory forces:

  • If you don’t want to get deep in the design (after all, you are in an estimation meeting) you end up with a very similar set of tasks for many stories: design meeting, implementation, testing, documentation…

    Regarding to this, I found very artificial to estimate the hours you spend writing tests and implementing something. Can you separate both activities in a realistic way?

  • If you get deep in the design inside a planning meeting so you can create very specific tasks, then you are mixing two very different activities: design and planning. Each requires a very high amount of energy. I have found far more productive to postpone design discussions for late meetings where people can focus completely in the thing to be designed. When you are in a planning meeting you look at the whole number of stories from a very high point of view.

In my opinion, the main advantage of having tasks estimated in hours is that you can see how many hours are burnt daily in the sprint backlog, so it’s very clear how the team advances each day. However, only with the daily meeting and keeping the stories small you can perceive a good sprint progress information.

While the story-points estimations worked very well for estimating our release planning, I found that splitting and estimation of tasks with hours was very inaccurate and someway artificial.

So we decided to stop splitting stories into tasks (not only stop estimating them in hours, we stopped managing tasks as first-class planning artifacts). We want very small stories so we force ourselves to split them when necessary (while keeping them tracer bullets). And I don’t really miss tasks. Certainly, there are many times where it is useful to write down the high-level tasks that are needed for implementing some story, but we are fine capturing them as informal comments with the story.

In this process of improving our development method, we first used Excel templates for managing our backlogs. After that, we used Agilo: a very nice tool based on trac that can be easily deployed as a VMWare Appliance. It supported perfectly the estimation in story points and hours for the product backlog and the sprint backlog, respectively. When we changed our planning approach we started using Pivotal Tracker. Pivotal Tracker is an amazing tool. Funny enough, I proposed to their creators to have the possibility of dividing stories into tasks and estimating them in hours. Many people liked this feature, which is currently the number 8th in Pivotal Tracker Most popular topics. The first topic was add tasks to a story and they have already implemented it in a very nice and simple way (with no estimations of course).

In sum, in our current process:

• We have iterations of 2 weeks (we preferred a shorter delivery cycle)
• We manage user stories as the only planning artifact in our backlogs (release, product and sprint).
• We use tasks for clarification of some stories, not as a general planning item.

Today, I’m not so convinced that this analogy is a good one. I can’t agree more with this quote from Dave Thomas (the Pragmatic Programmers proposed a new analogy that I’m pretty sure not everyone can digest):

Software development is neither. Nor is it art. It’s just software development. People who look for the “software is like xxx” analogies are missing the point. Software development is like software development. Let’s decide what works for us, and have fun while doing it

If you are interested, Martin Fowler explains the reasons why the building bridges analogy fails. I think, there is a sentence in his article that summarizes the problem very well:

Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

This question is, obviously, rhetorical. You won’t. Traditionally, the gap between models and code has been huge. If you ignore this gap, then you may think that you have to make great efforts in creating very rich models, so the low-skilled and no-talented programmer can translate them into working code. And if you can create these models, then nothing stops you from planning the full development process up-front. Since the construction phase is mechanical and predictable, then you only have to calculate how much time you will have to spend in modeling. And since modeling is about drawing (if we use this development approach we are using UML for modeling everything for sure), this estimation should be easy too. After all, drawings, like Word documents or Power Point slides, always compile and work. Of course, this scenery would mean that software projects are delivered on time, that the waterfall approach works, and that no matter wether the developers are talented or not.

In my opinion, the fact that models can’t be converted into code easily is addressed by the two development approaches I am more interested in:

• Agile development

• Model Driven Engineering (MDE)

Although both approaches are perfectly compatible, they propose different ways when it comes to use models. Both approaches see models as a communication tool, as a resource that let us, as humans, reason and elaborate solutions that solve complex problems. While agile practitioners warns you against using models for anything more than this, MDE practitioners propose to take the next step and convert models into first-class development artifacts.

The two approaches give different answers to the question of being able to create designs that can turn the coding into a predictable activity:

• Agile developers’ answer is “no”. In fact, they propose to use many good development practices and exhaustive testing as a shield against problems when coding. Coding is not an ugly phase, neither is cleanly separated from design. There are not designers and programmers, there are developers. They will use models as a way to collaboratively obtain the best designs that solve the problem, not as a way of documenting it. And since they assume they can’t predict how the full process is going to be in earlier stages with detail, they are going to estimate and develop the project iteratively, using an empirical estimating approach.

• The MDE answer is a little bit more complex to say, since the paradigm is in its earlier stages. But if we manage to have MDE solutions where we can define the best DSLs to describe a problem, and to specify how this input is translated into a working application, then, if these DSLs are defined in a way that are reusable in different instances of the same problem, we would be very close to being able to answer “yes” to that question.

By the way, a confluence of both approaches can be seen in the BDD (Behavioral Driven Development) frameworks: such as RSpec, Concordion or Cucumber, but I think that topic deserves a post on its own.

So today I decided to look for application that was SCRUM-specific. Sincerely I didn’t expect to find anything, nor I had any concrete application in mind. The app store search dialog suggested ScrumTools. It’s a very very simple, but still useful, iPhone app. In its current version it offers two things:

• A timer for controlling the daily meeting length.
• An electronic deck for playing the planning poker activity.

Although books usually recommend it, I had never used a timer to control the daily meeting length. If you don’t take care, these meetings can be easily longer than the 15 minutes recommendation. Since members of the team expose their problems, discussions about how to solve things tend to appear quite often. The solution is as simple as delaying further discussions for specific meetings. The iPhone ScrumTools alerts at 10, 5 and 1 minutes remaining (the normal iPhone timer won’t do this). I thing is a very good way of focusing the meeting in answering the three questions

Regarding to the Planning Poker activity, if you don’t know what it is about, you should read Mike Cohn’s book on Agile Estimating and Planning. It’s the best book on agile development I have read. Planning Poker is a technique for estimating size in software development. Basically, for each story:

1. The story is presented and the team discuss about it.
2. The members of the team choose a card that represents their estimation. We use story points in the set proposed by Cohn (1,2,3,5,8,13).
3. Everyone turn their cards over at the same time.
4. The members with the lowest and highest estimation expose their reasons, and then the estimation process is repeated.

The book tells that teams will find consensus soon. I was a bit skeptical about this after reading the book, but practice has taught me that a consensus is usually reached quickly.

• Start with test
• Don’t have arguments

Given a TestCase object, JUnit TestSuites can dynamically extract test methods that follow these conventions and run them on the fly. However, this behavior isn’t enough in some cases. The problem of this approach is that, from the developer’s point of view, tests must be written statically.

Imagine you have a directory with many text files. For each file, you want to do the same kind of testing. Since the test result depends on each file, what you really want is to generate dynamically test cases. Of course you can have a single test method, and do all the testing there. The main problem of this approach is that Test Runners won’t be able to collect results properly: a single fail with one file would result as a failure. You won’t notice which tests are valid and which aren’t.

Generating tests cases dynamically is very simple. JUnit’s design itself is simple. This is one of the main reasons of why this framework is so successful. JUnit was created by Kent Beck and Erich Gamma. It represents an excellent oportunity to see GOF design patterns in action (in the same way that JHotDraw, another framework created by Erich Gamma as a design patterns exercise). In JUnit, a Test Case is, surprisingly, a Test Case. A Test Suite is a composite of Test Case. You can create a Test Suite as a normal object and, programmatically, populate it with as many instances of a test case as you want.

Let’s see a very simple example. Imagine you have the following structure of folders:

For each folder, you want to create a Test Suite. For each file, you want to test that its extension must be .txt. In this way, you are going to create a parallel structure using test suites and test cases.

Below, the test suite is shown. It receives a directory in the constructor. It goes through all the contained files and subdirectories. For each subdirectory, a new TestSuite is created and added to the composite (recursively). For each file, a new TestCase is created and added in the same way. The actual testing is going to be done in these test case instances.

The test case’s implementation is very straighforward. It receives the concrete file to test in the constructor. It also overrides the runTest() method, where the real testing code is placed.

And that’s all. You can now check the results on a Test Runner:

With the exposed structure of folders, you will obtain something like this: