Ask HN: Any tools for measuring engineering/development process?
6 comments
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.
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.
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?
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...
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...
Pinpoint is solving for this
https://pinpoint.com
https://pinpoint.com
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.
Read
https://www.amazon.com/Software-Estimation-Demystifying-Deve...
and
https://www.amazon.com/Rapid-Development-Taming-Software-Sch...
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.
https://www.amazon.com/Software-Estimation-Demystifying-Deve...
and
https://www.amazon.com/Rapid-Development-Taming-Software-Sch...
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.
May be also help in onboarding and off-boarding new team members.