In our world metric plays a very important role in enabling us to answer questions and solve problems. A good metric would always provide valuable information to the team. There are good and bad reasons to gather metrics.
Good Reasons
------------------
This metric is very self explanatory. It helps team find it's true potential.
3) Product Burndown Chart with Standard deviation (More here)
By looking at it team can find out weather they will going to go live at the expected time or will need to do some adjustments.
4) Velocity chart per iteration (It is not burndown chart):
It is team's velocity over the period of time and an average line showing the trend. It is difficult to look at the raw data and infer if team is improving or not but black like clearly indicate that team is getting better over time.
5) Impediments (anything which is slowing team) per Iteration:
Simple yet very powerful metrics.
6) Risk burndown per Iteration: I follow Mike Cohn's prescribed approach and works perfectly fine in our context.
7) Product Owner's Time per day: This metric is very useful if you have same problem like ours. Our product owner was divided amongst lots of work stream. He could not spend time with team at all, so having a metric like these helped us resolve the issue with upper management.
8) Defects per demo metric: The title pretty much explains the purpose.
9) Number of unscheduled requests per iteration: Gather this data if your team getting requests from outside forces a lot.
10) Wait time per iteration: Any time team is waiting for response from DBA or Production Deployment teams or Any external dependency on regular basis.
11) Wasting of time per iteration: One of my team's lots of time was getting wasted on an old tool. We had to use that tool since it was company standard. We started tracking time we were wasting per iteration on that tool and got it replaced after 6 iterations.
12) Team Expenses vs. ROI per Iteration: I believe this is a very important metric in agile team. How quickly are we being able to delivery value?
13) Behavior per Iteration: This can be anything which you would like to capture over time. i.e. Code coverage per iteration, number of attendees per demo etc.
These are few metrics which I have in my toolbox. Let me know anything interesting you have tried which has worked very nicely for your team.
Cheers!
Manisha
Good Reasons
------------------
- To understand one's own progress
- To solve a problem with the data
Bad Reasons
----------------
- To facilitate competition between teams
- To motivate a team to do better (Motivation should come within the team. It should not be extrinsic.)
- To have control over a team
- To set a goal or incentive for a team
A good metric should set a mood at a glance from across the room. By looking at it, you should be able to say a trend or behavior over time. A metric should either make you feel good or make you feel bad, depending upon what you see. It's aim should be to generate right behavior and discussion in the team room.
Example of few team room metrics:
1) Total # Backlog items by week
By looking at this graph you can say week 6 lots of requirement got added. How so many new requirements got discovered? what are those new functionality? It will definitely going to make few people think about them and would make team look deeper into these new requirements.
2) Commitment vs. Capacity per iteration:
This metric is very self explanatory. It helps team find it's true potential.
3) Product Burndown Chart with Standard deviation (More here)
4) Velocity chart per iteration (It is not burndown chart):
5) Impediments (anything which is slowing team) per Iteration:
6) Risk burndown per Iteration: I follow Mike Cohn's prescribed approach and works perfectly fine in our context.
7) Product Owner's Time per day: This metric is very useful if you have same problem like ours. Our product owner was divided amongst lots of work stream. He could not spend time with team at all, so having a metric like these helped us resolve the issue with upper management.
8) Defects per demo metric: The title pretty much explains the purpose.
9) Number of unscheduled requests per iteration: Gather this data if your team getting requests from outside forces a lot.
10) Wait time per iteration: Any time team is waiting for response from DBA or Production Deployment teams or Any external dependency on regular basis.
11) Wasting of time per iteration: One of my team's lots of time was getting wasted on an old tool. We had to use that tool since it was company standard. We started tracking time we were wasting per iteration on that tool and got it replaced after 6 iterations.
12) Team Expenses vs. ROI per Iteration: I believe this is a very important metric in agile team. How quickly are we being able to delivery value?
13) Behavior per Iteration: This can be anything which you would like to capture over time. i.e. Code coverage per iteration, number of attendees per demo etc.
These are few metrics which I have in my toolbox. Let me know anything interesting you have tried which has worked very nicely for your team.
Cheers!
Manisha
Betway Casino Review (2021) - Gooyang FC
ReplyDeleteBetway offers a range 888스포츠 of the most pcie 슬롯 interesting 토토 랜드 같은 사이트 betting markets in the world 포커스트레이트 including online sportsbooks, 온라인 슬롯 casino games, virtual sports, live games