Writing software can have a bit of a pile of metrics to pay attention to. I especially hate being held toward measurements I cannot get control of. One of the worst offenders can be the ‘Story Point.’
The Problem of Story Points
The story point starts with the best intentions. It gives a way to for a team to build consensus about how big something ‘feels’ without the burden of a deadline. Project managers can get a general gauge of velocity, and an idea of how long a project will take to complete. But there are some glaring holes.
First, there is no baseline for a story point. What’s a 1? Without a definition of the base, what does it mean when a team estimates something at an 8? Is an ‘8’ in fact 8 times bigger than 1? If not, what’s the value of a velocity ‘sum’? If you can’t trust 1+1 to equal 2, the fact that your team got 35 points done in a sprint is meaningless.
Second, in my day-to-day developer role, I can only minimally impact the larger measure of velocity with story points. My largest impact is simply showing up for work. In effect, velocity largely measures who was on vacation for a given week.
Metrics I Care About
Things that get measured, get improved.
There are plenty of things I can demonstrably impact as a developer though. I can write more LOC, or less. I can measure test case counts and the code-coverage of those tests. I can measure the complexity of functions and classes. I can measure the depth of dependency usage, and the number of interface implementations. I can count external dependencies, or compiler warnings. I can do stupidly easy stuff and count the number of ‘.Result’ calls on async methods. (Quick tip, your target is 0.)
It comes down to a issue of my own design though. The trick is to decide what that design is, and how to measure it. For my own aesthetic, I prefer the following:
- Small code, thoroughly-tested, released often.
- Code which is apparent in purpose and function.
- Code with minimal external dependencies, which can be quickly replaced when warranted.
These are my design preferences, and having them help lead me towards the metrics I care about.
Small code, thoroughly-tested, released often = Cyclomatic complexity + Unit Test Coverage * Count of the number of deployments. These are simple numbers I can get out of build tools, and can ‘fiddle with’ right there in my editor. I can target small commits that are easily released to boot. I might not be directly able to control the release schedule, but I can target code that CAN be released often.
Code which is apparent in purpose and function = Average function length / Average class size * Average length of time commits are in code review. Again, I can fiddle with function length and class size directly in my editor, and I can make smaller commits / review sessions. I can do this every day to improve these numbers.
Code with minimal external dependencies = Count them. Did I install a Nuget package that came with 6 dependencies? Is there a comparable package that only has 2? If not, can I make one? If I don’t have time, can I minimize the surface area of that package? All of those items are directly under my control.
Communicate, Communicate, Communicate
Since I have my design aesthetics and metrics that show them, I can use them to communicate value and even push them further beyond story point as a measure of value. Some examples:
PM: We only completed 25 story points this sprint. Last sprint, we got 32. 😦
Me: We improved our test coverage by 28%, and last sprint, we had only gone up 4%. Our system is more robust against failure.
or
Me: We released 7 times this sprint! Last sprint, we released 5.
or
Me: Our average function length decreased by 8.5 lines, and our cyclomatic complexity stayed the same. That means our system is easier to work with for the next sprint!
Will my PM always understand these metrics? Probably not, but then my job is to get involved and communicate my values!
I might have to compromise. You don’t get to win everything, but having your principles backed with hard numbers is a much better way to win something and exercise some authority on some of your work.
I would rather be a stakeholder in what I am building than a cog in the machine.
Developers – Know Thyself
I am not suggesting that we change everything about story points or project management in a software project. There are better minds than mine on that. However, developers should do everything they can to decide how they want to write their code, and how to measure their improvement. Be regular, diligent, honest and thorough measuring your work. It is the best way to improve what you actually care about.
Christopher Brown's - Blog 