I find using points an excellent tool to estimate and track the progress of a project. There are advantages with using points, such as separating the estimation of size from the estimation of time, and that it comes quite naturally to estimate the relative size of one story to another. I find that the process of estimation goes much smoother, once you get the hang of it, than the more traditional approach. You steer clear of questions about padding the estimates. Who is going to implement what? And the general fear developers have of estimates becoming promises.

Visually tracking the progress of the project using a burn chart is a simple way to report how many of the features we can accomplish per week. From this we can extrapolate an estimate of when we’re done. This estimate will become more and more accurate as we complete iterations as we can use the velocity of old iterations to predict the future.

The downside with using the abstract concept of points is that it is often hard to sell the idea to an organization that for very valid reasons wants to deal with time. When I’ve started talking about using an abstract term like points for estimation, I’ve received my fair share of looks that can only be interpreted as “You don’t make any sense at all, man!”

So what do you do when you as a project team want to use story points and burn-charts while other parts of the organization want information to be reported in MS Project or similar?

I think the following more general advice applies:

• Recognize the request as valid and work towards giving project stakeholders what they need in order to make the best decisions possible.
• At the same time, be open about what you as a team need in order to make the best job possible. If the team think using points will improve the way they estimate and track progress, calmly present that to the organization and be prepared to answer the question why you need to work that way, what problem does that solve that other approaches don’t?
• Be prepared to compromise. The goal here is to find a way for the whole organization to work better. Not have the developers work better at the expense of some other part of organization, right?

As an example, here is how we are currently solving that we have different approaches to track progress. At the start of the project we had a release planning session where we divided the project into a handful of internal releases. Within each release, we grouped features that work on similar functionality into themes that were given a name. Each release contained somewhere around five themes. Each of the themes were added as an activity to an MS Project plan and was given an estimate like “this will take 2 developers 1 week”. The team then used points when estimating individual features or stories, which gave us a number of points for each individual theme as well as for the project as we knew it then.

We are currently tracking progress using the number of points we can achieve per week. This gives us a velocity of about 8 points per week. From the velocity we can extrapolate how much time is left of each theme and the project as a whole. This makes it easy enough to translate this into information that can be used to update the MS Project plan.

Our progress can now be viewed as either a burn-up chart or a critical chain fever chart. Having access to both types of information suite the needs of different parts of the organization. Better yet, we now have a concrete example to use as a base for, as objectively as possible, discussing ways to track progress. We can compare the different ways of presenting information and discuss possible deviations in what they report, and together come up with a better approach for next time.

Discusses the need for a clear cut exit criteria for a planned feature and how a test is one way to go.

In the project I am currently involved in, we release software once a month. We have currently released the first increment of work, and one of the activities we start after a release like this is to start some more formal tests of the software, performed by the project’s test lead and test engineers.

These tests discovered defects that really shouldn’t have made it in to the release at all. These defects revealed that we missed to implement some details in the requested functions for the release; things like missing to display a column in a list view etc. These were things that were clearly described in the user stories and in the tests performed by the testers. All the info needed was there. How is it then that we missed to implement them?

We did our best to avoid these misses within the project. All team members; software developers, leads, testers, and documenters sit together all the times. We have also made sure to involve all team members in all aspects of the project from day one so that we all have good knowledge about why we’re doing the project, how we’re designing and developing the software, and when things are ready for release. Besides delivering software once a month we also work in one week iterations, making sure to deliver a new chunk of functionality every week that can be demonstrated to team members and project stakeholders. We practice TDD to get a good adaptable design and to find all glitches before we hand stuff over to test and project stakeholders.

With all this in place the formal testing done by the testers should just be a formality, right? Well, the tests were quite successful. We found very few defects in the software delivered by the project; there were no major crashes or completely misunderstood requirements. We were pretty close to the target altogether. But what made us fail to implement some parts of the requirements?

The problem was that it was up to each pair of developers to decide when they were done with a feature. From time to time a pair would proclaim a feature done in the stand-up meeting one day only to report that they “performed some cleanup” of the same feature at the next meeting. It is so rewarding to be able to go up to the project whiteboard and be able to move a post-it from the “in progress” field to the “done” field. It is quite addictive really. Seeing the burn chart move closer to the finish line gives you a warm sense of accomplishment that sometimes make you miss a “minor detail or two” as you are so eager to step up to the whiteboard and get your reward.

To prevent this, we need a clear cut criterion for considering a feature ready. From this release on, we make sure that the test is available before the feature is implemented, both as a manual and as an automated Fitnesse test. The idea is that implementing a feature with the tests ready before hand should be like taking an exam and have the answers available before you start.

As a developer you have to make sure that the test for the feature in question has passed before you can consider it to be done. This will both give feedback on how well the implementation matches the expected result as well as verify that the tests make sense.