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.

    Cheers,

    Peter


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s




Twitter Updates

May 2008
S M T W T F S
« Apr   Jun »
 123
45678910
11121314151617
18192021222324
25262728293031

%d bloggers like this: