AgileAgile SAPProject managementScrumSmartSmart use case points (SUCP)Smart use casesSoftware estimation

Measuring agile progress in smart use case points

Smart use cases serve as a very good unit of work in agile projects. The agile process Smart relies on smart use cases, from start to end. Moreover, the progress in Smart projects is measured and managed using these use cases, and the associated straightforward estimation technique smart estimation.

First cut smart use cases

A first cut smart use case model is produced early in a Smart project, preferably during the first iteration, branded as the Propose iteration. The main product for this first iteration is a project proposal. A crucial element in this proposal is a project estimate based on the smart use case model.

The complexity of a smart use case is expressed in smart use case points. A simple and straightforward scale (1, 2, 3, 4, 5, 8, and 10) is available to produce this estimate – in most cases in a smart estimation poker session.

IMGP3613

Next, during Realize iterations, that form the body of a Smart project, the software is produced per smart use case.  A the start of an iteration the customer picks the smart use cases to realize. The number of smart use cases the customer is allowed to pick is dependent on the team’s iteration velocity, that is the number of smart use case points they have realized over the previous iteration.

A simple smart use case dashboard

The backlog of smart use cases, and the associated smart estimation allow us to measure and manage progress in our projects using the simplest of tooling.

IMG_0217

First of all, the smart use cases in the iteration backlog are written down on post-it, normally with their estimate in the lower right (or left) corner. The stages a smart use cases can have are depicted as swim lanes  on the dashboard. Normally during the daily stand-up meeting the team moves the post-it from left to right.

Measure agile progress

To be able to measure and manage progress in our projects, we count smart use case points. The team is rewarded with the smart use case points for a smart use case when it is moved to the stage Accepted (or Done). Also, when use cases are dropped from the scope of the project by the customer, which sometimes happens the smart use case points count. Use cases in any other stage whatsoever do not count. It’s binary, you’ve either earned them or not.

We express the progress of our project in a number of simple graphs. In our experience, putting these graphs up on – or besides – our smart use case dashboard motivates the team to higher performance. It appears to be very rewarding moving the smart use cases to the right.

image

We normally use the following graphs:

  • Daily burn down. A simple figure on the whiteboard works wonders.  In this case, we’re done with 133 of a total of 310 smart use case points. This means that we are at about 40% of the project. Not 40% of the analysis, or 40% or the design of the project, but 40% REALLY done.
  • Project burn down. The most used graph in an agile project is the burn down chart. This chart represents the progress of the project in a historical perspective. It displays time on the horizontal axis, and the number of remaining smart use case points dotted on the chart. What’s nice about a burn down chart is that it allows you to draw a trend line through the chart to determine the expects end date of the project. This can already be done at a very early stage, allow the team to manage possible overruns early.
  • Iteration burn up. We use a similar chart per iteration. It contains a dotted line representing the number of smart use case points already rewarded during the current iteration. In the example above, a second dotted line is present. In this particular case, this line represents the iteration burn down. We did this because during the iteration some use cases where re-estimated and progress wasn’t showing directly.
  • Iteration velocity. A very simple, but very interesting chart is the iteration velocity diagram. It contains a bar for each of the project’s iterations. The height of the bar represents the number of realized smart use case points. Normally this diagram also contains a horizontal line that represents the average number of points realized. This diagram is particularly useful when deciding the number of smart use cases to be realized during iteration kick-off.
  • Project status. This pie chart shows the number of smart use case points in each of statuses they are in. This chart for instance shows that 30.3% of the smart use cases (counted in smart use case points) is done, 3.8% is in test, and 48.7% of all smart use cases is still new (meaning they are identified, but no work is done yet – very YAGNI).

Together, these five simple and straightforward chart will help you demonstrate the project’s progress at any arbitrary moment during the execution of the project. It motivates the team, and proves to the customer that you’re fast (or not). Moreover, any coincidentally passing manager, CIO and CFO, will stop and frown over these diagram and wonder why this project is able to predict when it’s done, and his other (traditional) projects can’t. At one time, we where doing four projects on the same floor. Each morning the program manager for these projects walked across the floor, and stopped at each of the project’s progress charts. In a mere few minutes he was updated.

P.S. When I left the customer’s office this afternoon, we just got halfway. We’re now at 160 / 310. Not bad for a 8 weeks old service oriented SAP project.