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,
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,
No comments:
Post a Comment