Debugging Velocity
Debugging Velocity
Ship new software products faster
About the Book
When building a new product, there is a lot of uncertainty and a lot of pressure. Even in a larger company, where resources are theoretically unlimited, you have top-notch teams, and deep industry expertise, delivering new products requires a mix of numerical finesse in addition to team wrangling.
There’s many It’s possible to over- or under-resource teams, screw up scope with inconsistent expectations, or have unclear outcomes beyond making the new product a big success. Good starting point. But doesn’t make it clear what to do on a day-to-day basis.
This book covers velocity in significant detail using lots of real-world examples, case studies, and specific problems resolved using this framework. In addition, you will discover:
- Why your ability to release new products quickly as a company is a “do or die” factor in your company’s success
- How it’s possible for time passing to work to your benefit, rather than being something that holds you back
- How to figure out if your company’s systemic factors are slowing you down, and why this matters
- Why realized velocity lies at the root of hitting your team’s target dates
- How to approach debugging a team’s velocity, as it is a lagging metric by design
- Why progress relative to a direction matters with new products, as we should expect the milestones to shift many times on successful new products
- Why over-focusing on velocity can slow your team down, and what to do instead
Table of Contents
- 1. The one thing Steve Jobs did that turned around Apple
-
2. The Kindergarten, the Construction site, and the Assembly Line
-
- Here’s what happened
- What does this mean
- Choosing the metaphor works that best for your company
- Key Takeaways
-
-
3. Why “work time” reduction is futile
-
- This is most obvious in team ball sports.
- How does overemphasizing work time play out quantitatively?
- Key Takeaways
-
-
4. Why estimating cognitive effort simplifies knowledge work
-
- Relative Cognitive Effort is what we’re imagining.
- 1. Story points are not measures of developer time required.
- 2. Story points related to time are a lagging indicator for team performance.
- 3. Story Points assume you fix all bugs & address problems as you discover them.
- 4. One team’s trash is another team’s treasure.
- Wait, can’t Story Point estimation be gamed?
- Example: Adding technical scope to an already tight schedule
- While not perfect, Story Points are primarily a tool for capacity planning, not whip cracking.
-
-
5. The 2020 Guide to Planning New Products using Story Points
-
- 1. Estimate story points directly
- 2. Translate T-shirt sizes into story points
- 3. Ron Jeffries’ option of 2 days max/task
- 4. #NoEstimates
- Doesn’t all this estimation just mean there is less time to do the actual work?
- Case study: Distributed estimation
- Case study: use T-Shirts for first cut of backlog estimation, then translate to story points
- Case Study: Estimating roadmap items (to appease overachieving stakeholders)
- Case study: Nitty-gritty technical estimation in person
- Key takeaways
-
-
6. How to derive expected velocity from strategic dates
-
- I’ve found a simple tool to help straddle the vision with operational reality.
- An even simpler example
- The new technology case: B2B enterprise software example
- What actually needed to be built to fulfill the vision.
- Sizing the scope by numeric gut feel
- Case study
- Takeaways
-
-
7. How to analyze the impact of velocity on your release date
-
- Case Study
- Step 1: Pull out the scope sizes from Jira
- Step 2: Create a key assumptions section
- Step 3: Fill out the remaining formulas to estimate your release date
- Step 4: Rinse and repeat for remaining versions on your backlog
- Step 5: Kick up the What If analysis using Excel’s scenario planner
-
-
8. How to determine if systemic factors slow down your teams’ velocity
-
- Local or global maximum?
- Three Examples of Systemic Factors
- 1. Resource Thrashing
- 2. Too many chiefs
- 3. Communication overhead
- Wait, so how do you get a globally optimal outcome if you can’t add either staffers or managers?
-
-
9. How to measure how much a software team is “gelling”
-
- What happened?
- What was different?
- Key takeaways
-
-
10. How to simplify a complicated process, so that even a 2.5 year old would understand them
-
- How it all started
- Wrap up and implementation
- What happened in practice
- Lessons learned
-
- 11. Why over-focussing on velocity causes the opposite effect
- 12. Checklist: How to speed up your software team
The Leanpub 60-day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them