Tag: Status Report

Managing Stakeholders in Agile Projects can be tough in large or old organisations. Have you heard this: “YES. We are agile. But you must tell me what I will get and when!” It’s painful.

The natural tension between Agile and Senior Stakeholder Structures

Upper management in large organisations and Programme Management structures (e.g. PMO) have a natural conflict of interests (or ‘tension’) with agile principles – i.e.

1. Management and PMO want details on what is going to be delivered and when – i.e. Definition Up Front! – and
2. The Agile product delivery team want to adapt and change dates and features as & when the customer/audience change – i.e. Definition When it’s NEEDED!

Addressing the tension – how to run Agile in large Stakeholder structures

So – how should we approach the comms around an Agile Project / Programme, and stakeholder management?

Clear “Release” / “Goal” Planning

1. Describe your Releases (i.e. the significant product drops / deliveries) clearly
2. Provide a clear 1-sider about each release, outlining what the business goals are

Manage expectations with “The Cone of Uncertainty”

1. For each aspect of the release, clearly define the expected variance of estimates, according to degree of certainty
2. So, if you have allowed e.g. 2 sprints / iterations for a feature, but do not plan to unpack the user stories until later on, assign an appropriate +/- 40% caveat to the estimation
3. For more info
   1. see Agile 101’s understanding the cone of uncertainty.
   2. or Wikipedia’s entry on Cone of Uncertainty.

Focus on Epic User Stories / High-level Features

i.e. use High Level Requirements (EPICS / Features / Themes) to define the delivery

1. Do not break down your Epics / Features into user stories unless:-
   1. They are about to go into iteration, or
   2. They are very high risk or unknown, and you can’t attach any estimation.
2. So – avoid breaking down the WHOLE delivery into User Stories.
   1. It is in direct conflict with Agile and Lean to invest in definition unless you NEED to.
   2. So – only spend the teams’ time on defining user stories at the point of implementation.
3. Keep these high level requirements flexible – this gives you agile wiggle room and scope flexibility at the point of implementation.
4. Estimate the Epics in Story Points or T-Shirt sizes.
   1. See estimation recommendations here from Agile 101.

Keep Progress Clear

1. Update your stakeholders regularly on where you are with Features / Epics implementation.
2. Use a simple format (e.g. Release Plan) to explain which workstreams are delivering which features, and when.

Run a High-Level RAID Log and reference your Epics

1. Use a RAID log to speak in Senior Stakeholder ‘lingo’.
2. Keep this light, and do not go into too much detail.
3. Update each sprint, or as serious RAID changes emerge.

Leave room to manoeuvre within your Epics

1. When defining your high level features or “Epics”, keep the scoping high-level.
2. Be clear and strategic about the scenarios and success criteria.
3. Assign risk information to your Epics – raise stakeholder awareness of which features are risky / giving issues.
   1. This will enable them to help you prioritise.
   2. In healthy organisations, this provides a diologue in which to descope and reprioritise high level features.

Include High Level “Non Functional Requirements” (NFR s)

1. Be sure to include any significant NFRs.
2. e.g. (and not limited to-) :
   1. Ingegration requirements.
   2. Load testing, User testing, Stakeholder Acceptance testing requirements.
   3. Performance testing.
   4. contingency for all of the above.

Communicate Agile Plans to Senior Stakeholders

Here are some reporting formats that you can use to communicate Agile plans to Senior Stakeholders: