Hot answers tagged

13

So this is something I'm dealing with right now in AOL. The constant desire of business to measure seeps even into agile organizations. The key is to make sure you are measuring in a way that does not damage the fabric of agile for the sake of measuring. We must always be very careful and mindful of Goodhart's Law: "When a measure becomes a target, it ...


10

TL;DR Scrum is not intrinsically about doing more work faster, although high-performing teams often do. Like most agile frameworks, Scrum is about doing just enough of the right work. Measuring the team against a target velocity is a Scrum anti-pattern, as is measuring productivity from the number of backlog items or story points completed. Instead, you ...


6

I can definitely feel your pain on this one. Unfortunately, it seems like the organization hasn't grasped the team concept of Agile. If your role is the SM, I would encourage you to educate the managers and directors on working differently. Agile/Scrum changes everything about the way we work, even the way we manage and review individuals. An example you ...


5

A metric would be a standard of measurement in the context of PM. A performance indicator on the other hand is also just a type of performance measurement. Both terms could be and are used synonymously, e.g. here. The K in KPI would be the difference if any. One would consider the Key performance indicators the most important metrics that provide the best ...


4

So right now, as an Engineer, I take a single task, mull over it for 4 weeks, make sure it contains no bugs at all and I am the best worker you ever had. Despite the fact that it took me 4 weeks to deliver such a simple task. On the other hand, you have QA, who is wildly dependent on getting a crappy Engineer assigned. The crappier the engineer, the more ...


4

I once read a case about a development organization - they were trying to improve the administration of justice in an underdeveloped country. They had a way to measure the administration of justice (IIRC, the % of decisions that were overturned on appeal or review). But they had no way to influence the actual decision. Root cause analysis indicated that ...


4

None. Any individual performance metrics should only be used for the benefit of the employee. Otherwise you're committing teamicide. Do you want to have your team members help each other out on problems? Coach each other on technologies? Do you want them to give you their best estimates? And just work on what is next on the list? Do you want them to ...


3

TL;DR Successful leaders measure project outcomes rather than individual productivity. Measuring individual productivity is generally an anti-pattern that obfuscates deeper structural problems. Do you have too many bugs? Turn your teams loose on reducing the amount of bugs released into production. Are bugs taking too long to fix? Get your developers and ...


3

The reason for my question is that research seems to be to unpredictable and non-linear in order to be measured in the same way as e.g. the production of a car. That is the whole basis of R&D. Ultimately your ability to forecast progress on a project is inversely proportional to how "researchy" it is. In other words, if you are early in your discovery ...


3

Wiki have good example about project overrun (it is about cost overrun, but in our case it doesn't matter). The text below I took from this article and adapted for your question's example: Time overrun can be described in multiple ways. As a percentage of the total time expenditure As a total percentage including and above the planned time As ...


3

Over the course of a year, how many times did another team member ask this person for help, get it, and still was not afraid to come back and ask for help again? Over the course of a year, how many features did this team member ship, to customers, that are used and were relatively free of bugs? During the last live site incident, how did this person ...


2

Actual time - planned time = variance at completion. The OP's option (a) is the SPIt in Earned Schedule. In this example, it results in 0.6667, which is this project's performance index, a valuable metric for future planning.


2

The simple answer: you want to measure cycle time against your backlog items, not the tasks under those. The goal is to measure how long it is taking to deliver a unit of work. Tasks are just things you do, not units of work being delivered. Your cycle time will vary by the size of the item, that isn't a problem. You want to look at your cycle time on a ...


2

You can't calculate EV on the 10 items yet because they aren't done, so you don't know what the total effort to complete them is. You could calculate EV on the 5 that were completed if you had estimates for those 5 independent of the other 5.


2

To put it bluntly, from a commercial perspective people only care if you deliver the project they requested within the time and budget you promised. I have intentionally chose the word "promised" because if you don't do a proper job at communicating things, people that don't understand how the project is built will take things as a promise. And when the ...


2

Notwithstanding that I am not sure what you are measuring, try reading the data cumulatively. For example, assuming 100% means the completion of 100 units, by the end of the first week, you should have completed 500 units. Using the percentages you provided, this means you did complete 480 cumulatively, or 96% (the same as the weekly average as you posted ...


1

TL;DR In this scenario for calculating Effort variance, should I consider only effort spent in completing 5 user stories or should I consider the effort spent for all the 10 user stories? You should use only the stories completed. You can't meaningfully measure deltas on effort expended on work you haven't completed. It's worth your while to identify ...


1

We see at the end of the sprints that not all the points are being completed. Yeah, this should not happen. Do everything you can to make this scenario very unlikely. For example, pull into the Sprint what would seem to be a ridiculously unambitious number of Product Backlog items (PBIs), with the aim of giving the team the experience of completing a Sprint ...


1

The first thing you need to ask yourself is for what reason your Team is tracking cycle time. If you're not currently tracking cycle time for tasks/subtasks, and you don't have any problems with doing so, then I see no reason for you start now. If you do need to track them for whatever reason, then I suggest using a rolling average - you take the average of ...


1

Use the term at any level you desire. If you need to discriminate one KPI from another, then simply name them: Process Alpha KPIs. If you own a process, let's say the F-35 assembly line, I'm pretty sure you'd have quite a few KPIs to monitor the health of your line, and if anyone else at LM would complain, you could tell them where to put their KPIs.


1

This really depends on the methodology you are using, the expertise, experience and the rigor of people you are working with. The time you allocate for the development matters as well, I have been working with people who tends to deliver on time even if it's not 100% completed. That being said, I can relate to this KPI and based on the few hundreds small ...


1

Am I late for the party? Well, there are many ways to arrive at the metrics and it depends on how you would want to prepare yourself for the future. For example, an in-depth analysis requires every data point to be captured - for example, if you consider the chain from the ticket assigned to your team to ticket closure by your Client, you will have various ...


1

This sounds like a homework question. A metric is a quantitative or qualitative measure of some sort that can be measured repeatedly. A KPI is a metric that is considered very important in predicting some kind of outcome or making a decision. Its also just a fancy term that MBA's and business people sometimes use for the word 'metric. When you're talking ...


1

In simple term, Metric is how you measure something and KPI can be outcome of the measurements. For example, In a production support every month you present no. of tickets(Metric) as a trend. KPI is the trend should show reducing tickets month on month.


1

Have a look at Earned Value Management (EVM). There you compare your currently Earned Value (EV) (usually the cost that were planned to complete a specific task) with the actual cost (AC) for the task or the cost planned (PV for planned value) to be achieved to a specific point in time. Having those three numbers, you get performance indices: Cost ...


1

It depends how you want to report on it. I suggest that each of the following are equally valid, and it is down to how you want to report it. As a percentage over-run: (Actual time - Planned time) * 100 / Planned time, so you suffered a (15 - 10) * 100 / 10 = 50% over-run. I would use this for reporting externally. As a time comparison: Actual time * 100 / ...


1

You would need to ensure that every project housed on the EPM Server is a) baselined and b) has progress added and any late tasks have been reforcasted. You could run a calculation I belive that would look at your project summary line and calculate what percentage of the overall duration the projects finish variance worked out as, and then using an icon to ...


1

I think the other answers have neglected an important part of your question: "...distinguish between good and "needs improvement" programmers?" I concur with the other answers that there may be better ways to look at this problem. All known programmers need improvement. This isn't a binary "good" vs "needs improvement". The challenge here is to match ...


1

I would add one more indicator: time estimated vs time needed to accomplish a task. Having this data shows "reliability" of programmers and vastly improves planning. After couple of months you will probably see some patterns regarding people or type of tasks.


Only top voted, non community-wiki answers of a minimum length are eligible