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


23

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


17

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


13

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


13

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


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


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


9

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


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

Velocity is based on guessed values, and a median over the last few sprints/iterations. Therefore, the value is not exact as such, but it is "exact enough" for looking into the future of the next few iterations. If you have a team of 8 people working in two week iterations, you would accumulate 80 man-days of "working power". If you want to recalculate the ...


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

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


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

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


5

I will qualify my contribution firstly by stating that I am not a technologist; however, I think this generalizes to task complexity and performance no matter the specialty. Complexity is a metric itself. However, it is qualitative and subjective. So it sounds like you are looking for a quantitatively measured condition that is always present with ...


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


5

Velocity is not something that is calculated, it is measured. Velocity is the amount of work that is completed in a Sprint. In this particular case, since you estimate work in Story Points, you will have a Velocity in Story Points. At the end of a Sprint, you can look at all of the work that is Done (per the Definition of Done), sum up the Story Points and ...


5

Your concern is absolutely correct. Velocity as a team improvement metric is problematic because an improving team will often see their velocity increase but just because the velocity increases doesn't mean the team is improving. What you really want to look at is value delivered. There are a number of ways to assign value to work. If your team is already ...


4

Think of schedule compression as the elasticity of the work. If you have zero compression opportunities, you have no slack in the schedule. Anything along the critical path slips to the right, all the activities along that path slip to the right. What the manager needs to know about schedule compression when asked What is your schedule compression is how ...


4

Unfortunately no, there are no 'typical' times - at least in the sense you're asking. As you correctly pointed out, each project is different, but beyond that, each team is different as well so that's going to factor into the time as well. Is it a co-located or dispersed team, are the team members on just this project or multiple projects (dividing ...


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