Team velocity
Velocity and story points are underrated. We assign story points during a team meeting where most stakeholders, PMs/POs, and developers are available. Of course, one could argue that prioritization is the sole responsibility of the PM or PO. Depending on your needs, you can always limit who can decide the value of those store points. But as the number of people decreases, then it introduces some arbitrariness. Alternatively, you can let the team vote, and PM has the final saying. At least this way team can bias the PM for being more objective.
Story points do not map to the difficulty or time span of tasks but rather their ‘business impacts and urgencies. As the urgency of an issue increases, the business impact increases. Velocity is the total story points delivered per given time. Thus it is an exact measurement of how much ‘value’ you deliver per team per given time frame.
Why do we use Velocity? Because by following its trend, we can understand if we are doing something right or wrong. Such as, we brought a new policy to the team or a new employee joined, which somehow caused the total cumulative Velocity of the team or the average Velocity per member to increase or decrease. Based on that, we can have clues about the impact of such changes.
Triaging is about assigning story points to the tasks, and there is no such thing as a priority. You never close issues due to inactivity or lack of time. Instead, you assign low story points so that no one picks them up unless they have anything else better to do. In many projects, issues are closed due to inactivity, perhaps to declutter the task list. But I’m afraid that’s not right. Having many tasks available is much better than having fewer tasks that would cause your team to be idle. Eventually, once you have a pool of tasks with story points, if a task becomes irrelevant or invalid or the value becomes 0 or done, only then can you close it.
How do you assign story points? I believe the good old way of planning poker is a good idea. But extra care is required, and many teams get entirely lost in this agile/scrum process, and they forget their objective is to deliver value, not the process itself. Great Erik Meijer was a critique of the entire agile process, I can’t say I agree with him about everything, but he does have a point.
Once the story points are assigned, all left is for the developers to pick whichever they like from the pool, as their objective is to maximize their Velocity. Note that this does not contradict tasks with deadlines. You can still assign deadlines to the issues if required as an additional constraint. In addition, optionally, you can introduce negative story points for those if the team fails to deliver them promptly as an incentive.
Developer and Team Performance
In performance reviews, managers decide on employee performance, mostly based on their observations and feedback from other parties. But doing so creates a lot of bias and causes friction during performance reviews if the reviewed person disagrees with those points. I’d say most performance reviews are almost arbitrary without any backing data but rather rumor/bias-driven.
Instead, you can measure developer performance by the rate of delivered story points. And you measure overall team performance by the geometric mean of each contributor’s velocity. We use geometric mean (multiply n numbers and take nth square root) to increase team collaboration and emphasize the idea that ‘no man is left behind’. If one of the team members becomes a low performer, they will significantly take the entire team’s average story point down due to the nature of geometric means. Thus such a methodology gives the team enough incentive to take care of each other so that they will either succeed together or fail as individuals.
One great example is from the famous anime Naruto.