HN Explorer

Ask HN: Any tools for measuring engineering/development process?

2 points by ss_y2n ↗ HN
Tools that may help Engineering Manager or CTO in small or mid size teams to build cadence around measuring delivery, output and align teams.

May be also help in onboarding and off-boarding new team members.

6 comments

[ 1.2 ms ] story [ 39.9 ms ] thread
troydavis
Before implementation (and probably before choosing who does what), have the engineering team(s) estimate effort required for each granular work item in their upcoming release/sprint/month/whatever. Afterwards, you’ll have a measurement of velocity. Pivotal does this with Tracker so they’ve documented it: https://www.pivotaltracker.com/help/articles/planning_with_v..., https://www.pivotaltracker.com/blog/healthier-approach-estim...

Note that, as they say, “Velocity is a planning tool, not a goal or a competition. Quality is a much healthier and more useful goal.“ However much effort you spend caring about velocity, spend many times as much caring about quality - code/implementation choices, UX, resulting impact to the product/business, etc.

ss_y2n
Quick question here: Is it not many times that the problem with estimates is scoping and not really the time estimate of the scope decided?
troydavis
Both the scope and the time estimate can be wildly inaccurate. The theory here is that the team must clear up scope ambiguity at some point. If that doesn't happen, through inaction, that ambiguity gets "resolved" by a developer deciding what should happen while they're writing the code - or worse, not deciding so the ambiguity only comes up when a user tries the app. We've all heard horror stories about this - "It does X! It should do Y" Well, the spec/user story/chat transcript/whatever doesn't mention X or Y."

So, yes, the root cause is often that the scope is undefined or unclear. The process of having the team estimate how long something will take to implement (in fairly small work units - think hours, not days[1]) tries to solve both of those.

With my developer hat on, if I'm handed a user story like "Sandy wants to export her transaction history to CSV" to be implemented in this release, I'm going to immediately ask a couple questions: can the user choose the length of data to export? What app(s) does the CSV need to be importable and tested with, if any? Does it contain different fields than the Web view? Can everyone do it, even less-privileged users?

We don't necessarily need to spend hours debating this stuff, we just need to decide it before implementation rather than during or after/not at all. It's probably a 2-4 hour meeting with the team, looking just at the things planned for the next ~2 weeks. In my example, if the scope answers are that the user doesn't need any control of what to export, the CSV doesn't need to be compatible with any specific app, and the CSV should contain the same fields as the Web view for everyone, then I really may have 1 work item that probably won't take a lot of time/points. OTOH, for each answer that isn't no, there's at least 1 more work item :-) You'll also get better because after the release, you'll come back and say "Well, this took 3x as long because none of us spotted <some complexity>."

The important elements are: doing this as a team, not individually (so everyone can spot scope ambiguity and implementation challenges); understanding that the goal isn't to be perfect in release 1, it's to get better over time; that even if you're wildly far off, the return on the time will be positive merely for the scoping questions.

IOW, as a byproduct of estimating points for velocity, your team gets a shot at clearing up the scope.

[1]: https://www.pivotaltracker.com/help/articles/estimating_stor...

tzvsi
Pinpoint is solving for this

https://pinpoint.com

ss_y2n
Are there any other companies doing this? Why not? Is it not a big enough problem to solve. Or is it that the actual buyer of such product and user of products differ from one another.