
Ask HN: Any tools for measuring engineering/development process? - ss_y2n
Tools that may help Engineering Manager or CTO in small or mid size teams to build cadence around measuring delivery, output and align teams.<p>May be also help in onboarding and off-boarding new team members.
======
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/help/articles/planning_with_velocity/),
[https://www.pivotaltracker.com/blog/healthier-approach-
estim...](https://www.pivotaltracker.com/blog/healthier-approach-estimating-
velocity)

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...](https://www.pivotaltracker.com/help/articles/estimating_stories/)

------
PaulHoule
Read

[https://www.amazon.com/Software-Estimation-Demystifying-
Deve...](https://www.amazon.com/Software-Estimation-Demystifying-Developer-
Practices/dp/0735605351)

and

[https://www.amazon.com/Rapid-Development-Taming-Software-
Sch...](https://www.amazon.com/Rapid-Development-Taming-Software-
Schedules/dp/1556159005/ref=sr_1_3?dchild=1&keywords=rapid+software+development&qid=1595944002&s=books&sr=1-3)

Also think: if the business does project A, how much money does that make for
us or save for us? From a developer standpoint I have gotten the business
people to tell me a value that is a fraction of the cost of the product. You
fold that one and free up resources for project B which is the other way
around.

------
tzvsi
Pinpoint is solving for this

[https://pinpoint.com](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.

