4 ms·
The distinction you mention here (idea-to-dev vs idea-to-live) could be really useful for us as we've been debating two paths for an MVP that we're currently wo
by klenwell 8y ago
The distinction you mention here (idea-to-dev vs idea-to-live) could be really useful for us as we've been debating two paths for an MVP that we're currently working on.
It's actually the management team that has been putting off release in favor of a more fully-formed MVP, whereas my team is eager to get a more minimal working version (that we're pretty sure our users would appreciate and is ready for production) into our users' hands.
One of my big concerns is that if I devote my time to focusing on figuring out these metrics (which still feel somewhat academic for our team at this point) then I'm going to be pulled away from more pressing concerns like reviewing PRs, providing technical guidance for the team, and simply working to get shit (or, rather, software of acceptable quality) out the door.
- ljf 8y agoI'd argue that you are in a 'strong' place if the mgmt is putting off releases - not the team. If you can be in 'can we release yet, can we release yet' frame, rather than 'when will this be ready to release?' frame, then you have a strong feature/value focused team. Again measuring the delays that are caused by mgmt, rather than you and you team, is really valuable. And as to time to sort out these metric - lean on jira etc to create these reports automatically - metrics and reporting should be as easy and as simple and as valuable as possible, or people simply won't track them - or care about reviewing them.