Scrum Master Certification Training Fees

In Agile, story points are used to estimate the effort or complexity of a task, rather than directly converting them to hours. However, some teams find it useful to establish an approximate relationship between story points and hours for better planning.

A common approach is to map story points to a range of hours, for example:

• 1 Story Point: ~4 to 6 hours
• 2 Story Points: ~6 to 12 hours
• 3 Story Points: ~12 to 16 hours
• 5 Story Points: ~16 to 24 hours

This is just an approximation and can vary depending on the team's velocity, experience, and complexity of the work.

Example:

Let's say you have a 2-week sprint with 3 developers, each working 6 hours per day.

• Total available hours per developer = 6 hours/day × 10 days = 60 hours
• Total available hours for the team = 60 hours × 3 developers = 180 hours

Now, suppose your team has agreed that 1 story point is roughly equal to 5 hours of work.

• For 180 hours, you can estimate how many story points your team can handle: 180 hours5 hours/story point=36 story points\frac{180 \, \text{hours}}{5 \, \text{hours/story point}} = 36 \, \text{story points}5hours/story point180hours=36story points

So, in this case, the team can handle around 36 story points in the sprint.

Would you like more examples based on a different number of hours or developers?

Question:

What are the Top 5 or 10 metrics that you choose at Team, Program, Portfolio level, and also for DevOps and Quality/testing area and why? Also, what key metrics you showcase to Business to engage them positively. It is a financial service based company already following agile at scale and has a complete CI/CD pipeline in place.

Answer:

For an interview, the purpose may be interviewer wants to understand what all metrics you know, and for that, you might use the above metrics mentioned. For practical purposes, the first thing I think we should ask is what is the goal of metrics and what specific questions they want to answer? Like if they want velocity what exactly they would like to understand from velocity. We need to understand those first.

To guide them is a nice thought. but we humans make judgment calls often on these metrics :) that's where the whole problem lies. People try to inflate metrics. So teams need safety first, probably the reason why any metrics in general theoretically sound fine but won't work practically.

At the team level or program level or any level. We must try to improve relentlessly and try to deliver more value with better quality. I know this sounds very generic, but I think that's where teams should start thinking about what metrics better suit them.

Team level

- Sprint burndown/burnup, Velocity, Estimation Variance, Scope Variance, Backlog Health, cycle time (Time to build, Time to Value), lead time, throughput, CFD, Escape Defects, Cost of Each Sprint, Cost of Rework, Escape Defects, Defect Density, Build Efficiency, Planned velocity vs actual velocity. Agile Maturity Assessment at each team level

Program level

- Program velocity, Program Predictability Measure (PPM), ROI, customer satisfaction, feature progress, PI Progress, Deployments and releases per PI, pl/release burndown by iteration, Agile Maturity Assessment at Program Level (ART level), Defect Density, % of test automation coverage, the success rate of builds

Portfolio Level: 

NPS, Team Happiness index