Metrics for Agile

As a Manager or Senior Manager, we track Agile projects. Most common metrics we should be tracking while overseeing a project are:-

Agile:-


Basic metrics we track in an Agile project are


* Sprint Burndown chart
Scrum teams pull out a certain scope from top of the Product Backlog into a time-boxed sprint. This report tracks the completion of work through the sprint and tells whether we are on track to meet the sprint goals.  X-axis represents time and y-axis refers to the amount of work left to complete, measured in story points or hours. Meeting the Sprint goal is completing all the forecasted work for the Sprint


Things to watch out for:-
*** Burndown line is not a gradual burndown but steep drops --> Scope is not being divided into manageable chunks i.e. < 4-6 hrs
*** Scope is getting added or changed mid way through a sprint
*** Meeting Sprint goals early each sprint --> Scrum team is not committing to enough scope
*** Missing Sprint goals every sprint --> Scrum team is committing to more scope than can deliver


* Epic Burndown / Release Burndown (planned vs. actual in terms of story points)
Important we track this metric, to keep a tab on overall scope. This indicates whether we are adding new requirements mid way and is a good metric to check the status of the release

* Velocity
Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting.

* Defects
Though not a common Agile metric, as part of our waterfall gene we carry, we tend to watch the following metrics also as a good practice as this related to the quality of the deliverables


*** How many defects are found during development?
*** How many defects are found after release to customers?
*** How many defects are found by people outside of the team?
*** How many defects are deferred to a future release?
*** How many customer support requests are coming in on our delivered code?
*** What is the percentage of automated test coverage?

Governance using Agile Metrics
The above agile metrics surely gives a quantitative insight into the team's performance and provide measurable goals for the team

In practice, Sprint Burndown should be looked at during daily stand up calls along with the Scrum team.

Sprint Burndown, Epic Burndown and Defects related metrics should be explained out as appropriate to team during the retrospective meetings, while we answer the 3W's  - what went well, what didn't go well, what can we do better.

Output of retrospective meetings, should include actions items on continuous improvement feedback to ourselves as a scrum team and also with onsite/customer especially as this is the data point to be shown when scope creeps continue to happen during the sprint, which aids to not meeting the Sprint goals and having to re-plan every time and will be chaos in tracking the sprint goals

While the agile metrics are important, don't get obsessed. Listening to the team's feedback during retrospectives is equally important in growing trust across the team, working as a team, quality in the product, and development speed through the release process. Use both the quantitative and qualitative feedback in tracking the projects.

Most common agile tools are JIRA, Team Foundation Server, Grasshopper

Basic documents we use in Agile are Product Backlog, Release Backlog, Sprint Backlog, User Story Acceptance Criteria, Technical Design Approach, Retrospective notes,

Lesson: Stakeholder Support/Requirements Mgmt/Design

Let's see how stakeholder support on all process areas is crucial for project success!

A Stakeholder who doesn’t push his people to gather the requirements elaborately is also allowing ownership and accountability to be slacking.

First stepping stone of success is failing.

Incomplete requirements capture leads to everything partially done and will fail during UAT testing, where you will have the team doing requirements and mockups when they have to certify and release to production.

Precious time, effort, money is lost due to a simple mistake like not capturing requirements fully and not paying attention to design

Developers who develop will be discovering questions as they develop, and as a result, design and coding need to change.

Project Deadline is never met, as we are failing in multiple disciplines of Project Delivery Requirements Management, Design including Project Management 

Stakeholder Management

Stakeholder Management as part of PMP has a lot of importance in real time and impacts revenue recognition, pipeline, cost, time. We gain this insight and effects mostly through experience and as part of guidance by our mentors and leaders in projects.

Standard Stages in Stakeholder Management are Identify Stakeholders, Plan Stakeholder Management, Manage Stakeholder Management, Control Stakeholder Management

Each of the below points should be studied as a case study with real examples, imbibe it strongly and ensure we plan properly:-

Please feel free to comment on additional things so others can learn from your experience

1) Stakeholder Change: 
It takes time to establish a trusted relationship and is often based on quality deliverables, good governance, good channels of communication, our delivery track record etc...

When this key customer stakeholder moves out of the equation, we need to start it all over with the new stakeholder.

This person's working style; priorities; needs; previous vendor preferences; their comfort with them;  getting things done; being there for consultation; walking their corridors, needs to be considered.

You need show the similar or higher technical and management prowess, attention and availability, good intentions to make them succeed. It involves writing a stakeholder plan and each party play their role.

2) Stakeholder Support across all stages of the project
Stakeholder support and prioritization towards your strategic initiative/project is a very important success factor.

If resources are being diverted over to other business as usual and urgent activities, it means they are steering the time and effort away from your current project and might not be giving required importance to make this project succeed. Any of the success factors failing will have an impact on the project.

Stakeholder support is required to clear obstacles fast, make decisions fast,  is equally important. If proper Stakeholder support is not being given, ensure you brace up with proper communication. Dipping into your sphere of influence to get required support can be done proactively to minimize the impact.

3) Regular Monthly Stakeholder Meeting for communication of expectations vs. reality from beginning to end. In case of crisis, weekly stakeholder meeting, to ensure it is going as per expectations and plan set

4) Expectations of internal stakeholders, leading to activities over and above other important activities required to achieve the project goal

5) Stakeholder current situation and priorities affecting the continuity

6) Communication on critical emails regarding milestones, risks, issues, delays, payments to stakeholders should be carefully drafted to preserve the interests of the company and SOW, which might be beneficial for future legal arbitration purposes.