Project management evaluate quality and productivity [closed]

Closed. This question is opinion-based. It is not currently accepti开发者_运维问答ng answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I was promoted as a project manager. This is a new role for me and at the beginning I find this job pretty hard.

Can you give me some example of metrics that I could use to measure the quality and productivity of my team members? I need to measure that for developers and for testers.

---

You can measure a lot of things

• lines of code produced.

• keystrokes.

• coffee consumed.

• trash produced.

However, that's just numerosity -- numbers for the sake of having numbers.

Before you measure your team, find out how you are measured.

Find out how your overall development organization is measured.

Find out what measurements the overall organization is trying to optimize.

Then -- and only then -- try to find a way to map the big picture goals down to your team. If you're not measuring progress toward the organization's overall goals, then you're just collecting numbers.

If you're going to collect numbers, weighing the coffee every morning may be the best indicator of work being done. Seriously.

---

This is a good link suggesting most metrics you choose will probably not end up working in the way you want. Developer Metrics - Useful or Harmful?

For example,

• measure lines of code, the impact will be verbose code

Any metric you choose will likely end up being 'gamed' by the people you are trying to measure.

---

Value delivered. Work with your customers (product owner) to find a way to measure value in your organization and measure that value. Deliver it frequently (daily, weekly, monthly) and you'll be just fine.

---

Can you give me some example of metrics that I could use to measure the quality and productivity of my team members.

A few examples of metrics for an Agile Team to measure PRODUCTIVITY:

Story Points / Velocity Points: This is a relatively sizable unit which can be used to measure complexity of the work to be done.

Sprint Burndown: This can be used to measure progress in hours during an iteration or Sprint

Release Burndown: This can be used to measure progress in story points during a release.

A few examples of metrics for an Agile Team to measure QUALITY:

Hudson CI: You could use a continuous integration tool which constantly keeps an eye on the code base for you automatically. Some plugins for quality checks that can be used could be: Corbertura PMD CheckStyle

---

Find out why your company was interested in adopting Scrum in the first place.

If it was to produce better quality code, then you could focus on things like test coverage, bug count, etc. I like the CRAP index.

Many companies adopt Scrum because most of their problems - including low quality code, tight deadlines and rework - are caused because they produce the wrong code in the first place. Either requirements are misunderstood, or the stakeholders don't quite know what they want. If that's your problem, you might want to measure throughput (how long it takes a story, on average, to go from analysis through to release) or feedback (how long it takes you to know whether the work you did is actually usable, or not - bearing in mind that when it's not usable, you want to know as soon as possible).

I try to avoid measuring things like productivity. It's very easy to be productive without being effective. Focus on the Goal. Most of the metrics in Kanban can be used alongside Scrum and will help here. I very much like Cumulative Flow Diagrams, because they show all kinds of feedback loops and constraints in the system.

Oh, whatever you do - measure the team, not individuals. As soon as people think they are being measured as individuals, they'll stop playing nice with the team.

---

Productivity is the only important measure of success: did my team accomplish what we said we could do, within the timeframes specified, and to a high level of quality (passing UAT)? If not, why not?

A good way to "measure" this is by measuring the team's velocity and then using that as a benchmark. Velocity represents both what the team can do as well as how accurately they are able to plan their own level of effort.

Here are a few good articles on velocity and how to calculate it:

http://www.versionone.com/Agile101/velocity.asp

http://michaellant.com/2010/07/23/calculating-the-velocity-of-your-agile-projects/

---

When I was first promoted to PM, a decade ago, I tried to track everything. Only one thing really matters in the end and that is the team's happiness (the team includes the client). If everyone is content with the pace, quality, and environment of the project then you only need to adapt whatever metrics help the team to improve. You can identify those metrics with the team in retrospectives. Whether they find velocity, functional points, lead and cycle time, test coverage, or any other metrics useful - those are the things you should help them to measure. I think the most powerful thing a new PM can focus on is communication, not measurement.