[SCRUMDEVELOPMENT] Indicators of status project for senior management

[[e-mail] [SCRUMDEVELOPMENT]]

Hello,

I have a request from my manager to prepare a model to be presented to senior managers on status for agile projects. Today they have a RAG status for three indicators: time, cost and quality (risks). Time and cost are based on deviation of earned value. Eg: costs exceeding 20% of planned is Red status.

I already presented to him burn up, but that is not feasible, as he'd like a simple dashboard and see status of all running projects.

Do you have any suggestions on that?

thanks, Daniel

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

At my last job, we presented status as an annotated high level backlog.
Say you have 10 epics/features/high level items. You draw 4 lines in the
BL: Completed, must-haves, estimated end of budget, and estimated end of
schedule.


Feature
------------------
Feature 1
Feature 2
Feature 3
Feature 4
-------------------------------- Features are completed to this point
Feature 5
Feature 6
-------------------------------- Features above are "must haves"
Feature 7
Feature 8
-------------------------------- Estimated end of budget
Feature 9
-------------------------------- Estimated end of schedule
Feature 10




This gives you a concise presentation of the status of the project. If the
end of budget or schedule lines ever goes above the must-have line, you
have a problem.

Post by ***@yahoo.com.br [SCRUMDEVELOPMENT]
Hello,
I have a request from my manager to prepare a model to be presented to
senior managers on status for agile projects. Today they have a RAG status
for three indicators: time, cost and quality (risks). Time and cost are
based on deviation of earned value. Eg: costs exceeding 20% of planned is
Red status.
I already presented to him burn up, but that is not feasible, as he'd like
a simple dashboard and see status of all running projects.
Do you have any suggestions on that?
thanks, Daniel

['Steve Ash' [e-mail] [SCRUMDEVELOPMENT]]

I concur with Cass on this although I prefer to use the Scrum terminology of ‘Backlog Items’ rather that ‘features’ – features is such a sloppy word and not equally understood by people that use it.



Basically, you can forget RAG; the only time that you are in trouble is when the Must Have line goes below the End of Budget or Schedule lines.



Hope that helps



Steve Ash

[[e-mail] [SCRUMDEVELOPMENT]]

Better still - get the senior manages on an Agile course so that they understand

[[e-mail] [SCRUMDEVELOPMENT]]

One of my previous replies seems to have gone astray!!


I said that you should get the managers to ask the Product Owners if they are happy, they are responsible for delivering business benefit after all.


Sounds like the senior managers do not trust the Product Owners or the Development Teams.


You need to sort this problem before supplying the senior managers with irrelevant reports

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I used the term features because our backlog items are usually at a much
finer granularity than is digestible by management. The term feature was
intended to imply a higher conceptual level than the PBL item

Post by 'Steve Ash' ***@ootac.com [SCRUMDEVELOPMENT]
I concur with Cass on this although I prefer to use the Scrum terminology
of ‘Backlog Items’ rather that ‘features’ – features is such a sloppy word
and not equally understood by people that use it.
Basically, you can forget RAG; the only time that you are in trouble is
when the Must Have line goes below the End of Budget or Schedule lines.
Hope that helps
*Steve Ash*

[Michael Vizdos [e-mail] [SCRUMDEVELOPMENT]]

Hi.

Can you invite them to the Sprint Review and have a face-to-face
conversation between the Scrum Team and the Senior Managers?

This is the best way for feedback versus status reports in either direction
and requires / shows commitment (and requires courage in organizations
where there is fear).

Thank you.

- mike vizdos
Focus. #deliver

www.implementingscrum.com
www.michaelvizdos.com

Post by Cass Dalton ***@gmail.com [SCRUMDEVELOPMENT]
I used the term features because our backlog items are usually at a much
finer granularity than is digestible by management. The term feature was
intended to imply a higher conceptual level than the PBL item
I concur with Cass on this although I prefer to use the Scrum terminology
of ‘Backlog Items’ rather that ‘features’ – features is such a sloppy word
and not equally understood by people that use it.
Basically, you can forget RAG; the only time that you are in trouble is
when the Must Have line goes below the End of Budget or Schedule lines.
Hope that helps
*Steve Ash*

[[e-mail] [SCRUMDEVELOPMENT]]

Thank you all for answers.

I'll try to propose it for senior managers.

br's, Daniel

[[e-mail] [SCRUMDEVELOPMENT]]

You can always ask the managers to ask the Product Owners if they are happy. It is their job to maximize business value after all!


This sort of report suggests that senior management does not trust the Product Owners or Development Teams - you should try to overcome this problem rather than producing irrelevant reports.


IMHO!!