Scrum reporting

Currently there is a need to devise practical means to know whether a project running with Scrum is on course to meet its goals. These means should also be used as input for management overview and portfolio management practices.

Some ideas can be found here, here, here and here.

I would say that, at the least, we should use burn down charts. And I was also thinking on “planned vs. actual features delivered by iteration” from here. But this, as already pointed out by a colleague (thanks Edisson), seems to be something like on time delivery metric. OTM metrics, in my opinion, don’t help too much as they show that something has already gone bad and not that something has a tendency to go bad.


1 Response to “Scrum reporting”

  1. 1 Peter August 5, 2008 at 2:11 pm

    Actually, you do check planned vs. delivered. Every Sprint, the team commits to a package of functionality. A formal definition of done assures that the work is completed to a defined quality standard. The sprint length is fixed as is the team. So the only thing which can vary is the delivered scope, and this is examined by the product owner at the end of every sprint.

    I have been looking at tracking quality metrics. I am thinking cumulative unit and acceptance tests, both total number written and number passed. This would give an objective measure of the state of the system, both internal quality and completeness.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Twitter Updates

May 2008
« Apr   Jun »

%d bloggers like this: