Hot answers tagged

25

My team uses Lego to track work done and what we're spending our time on. This was our last iteration (two weeks): The section at the front shows task completion. White bricks are added when a task is developer done and committed, orange bricks are added when they're QA complete. The section at the back shows what people spent their time on by day. We ...


24

Velocity is not a valid measure of team or process improvement. Velocity, especially when it is based on Story Points, is extremely unstable. By itself, Velocity doesn't reflect the capacity of the team, but capacity will limit Velocity. It's also easily disrupted by changes to the team's way of working (which includes the definition of what a Story Point ...


19

In my opinion, gamification of time-tracking shows that you've either failed to do anything worthwhile with time-tracking data, or you've failed to communicate the worthwhile things that you have done. A random website gives these as the top reasons to track time: Data for future project costing/estimation. The ability to value work in process (especially ...


18

TL;DR You can use tools like gitk, GitStats, or the GitHub graphs tab for a visual representation of repository activity. However, this is usually a bad idea from a project management perspective. The Wrong Metrics In general, measuring lines of code (LOC) or commit activity is the wrong way to measure a software project. You get what you measure, after ...


16

Deconstruction of the Project Manager Goal As a project manager, I could say something like "I will lead and execute X projects on time and in full with 95% satisfaction." Setting aside whether this sort of goal really fits the SMART criteria even for a traditional project manager role, it is not appropriate for a Scrum Master role. Here are some reasons ...


14

Most common metrics used along with Kanban are: Cycle time / production lead time There is some confusion over naming so let me explain in a bit more detail. Production lead time or cycle time is time that elapses from the moment a team starts actively working on a task till the moment they are done (or done-done). This metric basically say about how ...


14

There is nothing wrong with this type of scoring. This type of customer confidence score is the same general idea as NPS and a multitude of other score. Whether or not it is healthy is largely dependent on how it is used. First, it is important to understand what this score is and is not. It is a satisfaction score. It tells you about the individual's ...


13

Do other companies do this? Is it considered Agile? Can it show real insight? No. No. No. Why not? Because it's completely pointless. You said you have sprints. I guess they have tickets or stories in them. So you already have an objective measurement how you did. 8 of 10 stories done? 95 of 98 story points finished? There you go. Objective measurement. ...


12

TL;DR As a Scrum Master, I am unable to predict if the stories are progressing and getting completed as expected. I read that with the burn-down chart the team is burning hours and the tracking will be based on hours and not story points. The burn-down chart is the wrong tool for measuring progress. The correct tools would be: The daily stand-up, which ...


10

Summary To calculate velocity when using non-numeric relative sizing, you first need to map your story sizes to numeric values. I provide a working example of how to do this with tee shirt sizes, and then show how to calculate the mean velocity of some shirt-based Sprints. I also provide some of my thoughts on this as an agile technique, and some ...


10

All work is probabilistic. It has an extremely improbable best case result, an extremely improbable worst case result, and an extremely probable most likely result. That probabilistic distribution is driven by both random and non-random variables and a PM, no matter how talented, can do absolutely nothing about the random variables and can likely affect ...


9

Essentially, I want to be able to demonstrate the effectiveness of the recent time that we've spent dedicated to bug fixes. It's obviously good news that you've fixed all these bugs, but as a manager/senior stakeholder my first question would be why there were so many bugs to fix in the first place. Because of this I'd suggest that in addition to ...


9

TL; DR Low but steady velocity is usually fine. Steadily-declining velocity is a strong indicator of an unidentified process problem, which the Scrum team needs to identify and make clearly visible within the project. Velocity is a Range First of all, velocity is not meant to be either a management target nor a fixed value. It's an estimation tool, and is ...


8

TL;DR You already know you shouldn't do this. However, if you must do it, focus on team integration and support of team values, rather than trying to perpetuate the 100% utilization fallacy or applying irrelevant metrics like lines of code written or bugs stomped per iteration. If the person makes the team better or the process more effective, then they ...


7

As pointed out by CodeGnome, velocity is always going to be a range. However, if you find that your velocity fluctuates a lot, here are some things to check and suggestions for improvement: Do you account for holidays? For example, if you run 2-week sprints, you may have one sprint with 2 holidays which is 20% less duration than a normal 10-workday sprint....


7

"I'm wondering if a gamification approach to time tracking would help..." I believe that gamification has the potential to solve the problem with engagement, but it also generates some serious risks of unintended consequences. if very engaging, employees may spend too much time on time tracking / playing the game; this may make work more fun but may ...


7

TL;DR They have decided that if there are any User Stories not fully completed (as per the DoD) at the end of the Sprint, the Sprint has failed. This is not only incorrect, it's an abuse of the Scrum framework and a thorough misunderstanding of how work is selected for inclusion into a Sprint. The purpose of a Sprint is not to complete user stories. ...


7

What You're Offering This is a good question, because it highlights a common misunderstanding of agile principles and contracting. In practice, you aren't promising to deliver something with a fixed scope, budget, or timeline. What you're offering to do is to collaborate with the customer in iterative increments, and using framework features to manage scope ...


7

The direct answer to your question is that how you bill your time to the client is not addressed in Scrum. Therefor there is no billing model that is expressly anti-scrum. If adding a place on the board where you track time is the easiest way for your team to keep tabs on it, feel free. Now, there are billing models that can incentivize anti-Scrum behaviors. ...


6

Using historical data As the others have said, you'll need to estimate future outcomes, based on historical models. For best results, you need to do this with your own records. However, for benchmarking and validation, you can also look into buying extracts from commercially-available databases of software project metrics. QSM Project Database SPR ...


6

TL;DR There is no secret. Magic pixie dust is a controlled substance. You Get What You Measure This is a truism in management of any kind. You can't prevent side-effects, because any phenomenon is changed by the very act of observation. At best, you can use multiple dimensions to refine the measurements so that you reach a better approximation of your ...


6

TL;DR In your rather long question, this mixture of issues stood out as the gist of what you're really asking about: Sometimes a design will be approved the first time, but other times it'll take 5 iterations. The only thought I had was to maybe re-score every time I have to do an iteration & bump it to the top of my sprint since that's still ...


6

Story Points Are Never Time Estimates Is doing: S = 1/2 a day (maximum) M = a day (maximum) L = 2 days (maximum) a good approach? Absolutely not. Story points measure complexity and the level of effort required to complete a feature, including the team's Definition of Done. It is not, and should never be, directly mapped to units of ...


6

As the comments indicate, you create a metric to answer a question. If I just look at the title of your post, "Simplistic PM metrics for how ACTIVE [emphasis mine] a project is," the two metrics that pop out to measure activity are hours exhausted and money exhausted. If you are comparing projects against each other, then you need to compare hours or money ...


6

Scrum works best if you have good product ownership, fixed-length iterations and a stable team. If the backlog is determined by the client and the team is stable then (barring leave and unexpected absences) I would expect the cost per iteration to be fixed. So if you need to apportion cost per item then the right way is surely to divide the iteration cost (...


6

Yes, a project manager is responsible for completing a project on time. However, "on time" is a date that will often move during the life of the project, and it is the agreed date that the PM should be measured against - not necessarily the original date. The initial date may be agreed by all concerned, however requirements may change, issues are ...


5

I worked with one organisation that was in a similar position. They had starting adopting Scrum before measuring the effectiveness of the old way of working. They did find a few metrics to compare using historical data: They looked at old project documents/emails and measured how long it was from the initial work request to something going in to production,...


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 ...


5

TL;DR Calculating velocity is relatively straightforward if and only if you treat it as a rough estimate for forecasting. If your metrics imply great precision, you're using velocity wrong. Having said that, the two most common techniques are: Trailing average. Median with confidence intervals (e.g. "a range"). There are many variations on these ...


5

I understand where you are coming from. However, I am unable to understand what you are trying to achieve from this kind of measurement. This practice of capturing productivity per programmer / developer based on defects and KLOC has reached its dead end. The practice of measuring was only during the Mainframe days (extended until Procedural programming ...


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