Story Points For Roadmapping, Hours For Execution: Finding The Right Balance

Software development teams rely on estimates to plan, prioritize, and deliver work. Two common metrics used are story points and hours. Story points provide a relative measure of effort and complexity for product backlog items. Hours represent the actual development time spent implementing those items. Using both together, but for different purposes, helps strike the right balance between long-term roadmapping and short-term execution.

Why Both Story Points and Hours Matter

Story points and hours offer related but distinct views into a team’s capability to deliver software. Story points allow product owners and teams to forecast release plans over longer time horizons. They abstract away variability in a sprint to provide consistent estimating and tracking. Hours depict actual development effort at the iteration level. They enable organizations to monitor programmer productivity, identify delivery bottlenecks, and improve timeboxing.

Relying solely on hours can undermine roadmapping activities. Raw time fails to account for complexities underestimated in initial scoping. Consequently, projections of delivery lack adequate buffers for uncertainty. Conversely, ignoring hour trends misses opportunities to validate velocity assumptions and adjust capacity planning as needed. Using both story points and hours in balance provides the proper cadence between release planning and sprint execution.

Understanding Story Points

Defining Stories vs Tasks

Before assigning story points, product backlog items get split into user stories and tasks. Stories describe desired functionality from an end-user perspective. They align to business goals and follow the INVEST criteria – Independent, Negotiable, Valuable, Estimable, Small, and Testable. Teams then break stories down into granular, technical tasks required to implement the user story.

For example, an epic ticket to “Allow users to upload profile photos” gets split into multiple stories like “As an account holder, I can upload JPG/PNG images to associate with my user profile”. The development team further identifies specific tasks such as “Create S3 bucket for image storage”, “Build API endpoint for image uploads”, and “Render avatar pictures across site templates”.

Sizing Stories Using Relative Estimation

Accurate story point estimating relies on the concept of relative sizing. Rather than estimate in hours or days, agile practitioners comparatively gauge the amount of effort stories require relative to each other. Applying modified Fibonacci scales (e.g. 0, 1, 2, 3, 5, 8, etc.), they assign higher story points to items anticipated to take more work.

To promote consistency, teams define benchmark stories representing a single story point and five story points for comparative anchoring. Effort scores situations between those bounds accordingly. For example, a story twice as complex as the one pointer would earn two points. One expected to require significantly less work than the benchmark receives a fractional score.

Accounting for Unknowns and Uncertainty

Story points intentionally incorporate uncertainties overlooked by time estimates. Hour-based guesses frequently get proven wrong due to faulty assumptions, technology unknowns, and failure to account for interruptions. Story pointing against benchmarks containing similarly unpredictable elements circumvents available time heuristic biases. The wider variation in story points reflects suspect duration accuracy while honoring unanticipated impediments.

Additionally, bifurcating backlog items into stories and tasks isolates complexity sizing from implementation unknowns. Stories receive points for end goals while tasks facilitate discovery of previously unforeseen intricacies. Such decomposition avoids conflating effort with duration and concentrates volatility into smaller containers easier to re-assess.

Tracking Hours for Execution

Recording Actual Development Time

Whereas story points guide roadmap forecasting, development teams log hours specifically to record time invested per sprint. Doing so gives real data on tangible work output that accounts for all interruptions and context switching unavoidable during active coding.

Tracking hours proves useful to monitor several team metrics – developer capacity over sprints, average story point burn rates given man hours logged, actual velocity calculations, and resource allocation to initiatives. Anomalies between logged times versus story point assumptions provide signals to update stale estimates or address performance issues.

Identifying Delivery Speed and Throughput

Hour logging provides vital inputs to understand delivery reliability. Velocity, calculated using story points completed per sprint interval, conveys throughput expectations. Comparing sprint story point velocity against actual sprint hours gives insight into development speed. Contrasts pointing to excessive hours warn of roadblocks impeding team progress.

For example, if velocity forecasts 16 story points completed each sprint but point burn required 50% more hours than historically needed, impediments likely exist degrading team cadence. Lead times per story show similar trends. Lengthening cycles indicate congestion and stretch factors applied to story points to hit velocity targets.

Using Story Points for Roadmapping, Hours for Execution

Planning Releases Based on Story Point Capacity

Product owners prioritize the product backlog according to business value and size work efforts using story points. Understanding historical team throughput helped by story pointing, they can map priorities across several releases within a reasonable horizon. Building in buffers and risk adjustments, strategic roadmaps take shape.

For example, ten sprints containing approximately six developer full time equivalents (FTEs) working at a sustained rate of 16 story points completed per sprint yields capacity for 160 points. If the current product backlog totals 500 points, a six-month roadmap emerges by filtering, sequencing, and apportioning larger initiatives across three tentative releases.

Monitoring Velocity to Improve Estimates

Hour logging and tracking enables teams to monitor if initial story point estimates prove accurate over sprints. As work completes each iteration, time logged offers empirical data to compare against points guessed. Velocity metrics can validate estimating skills.

Suppose the team averages six member with capacity for sixteen story points per sprint. Members log average twenty-five hours per person-sprint. Completed stories earn an average two points. Thus, actual velocity calculates around 2 points per 25 logged hours. Estimates expecting 1 point stories to require twelve hours get affirmed while 3 pointers lasting only twenty hours may need reassessing.

Adjusting Scope Based on Hour Trends

Burn-up and burn-down charts plotting both hours worked and points burned provides important signals about team progress. Divergences between hours tracking higher than story point completions indicate falling behind delivery targets. Traveling releasable scope or resources requires rebalancing based on such empiric hour data.

For example, midway through a release, if the burn-down of story points remains on schedule but hours logged run significantly higher than plan, the release roadmap needs revalidation. Likely more hours will get needed for remaining work. The data suggests some stories took longer than expected. Removing or descoping some features becomes necessary to stay on track.

Maintaining a Sustainable Pace

A common agile retrospective question asks “Could we have sustained this pace forever?” Logging hours provides quantitative data to assess sustainability. Teams tracking hour trends against story pointing can empirically monitor cadence and prevent overexertion.

If logged hours per week per person consistently exceed forty, or if hours vary wildly sprint to sprint, pacing issues likely hamper consistency. Hour data informs the adjustment of story points planned per iteration to smoothen flows. Gradual tuning toward hour averages maintaining sustainable rates leads to improved forecasting and worker well-being.

Striking the Right Balance

When to Use Story Points vs Hours

Though related, story points and hours serve distinct purposes. Story points support product planning and scheduling for future sprints. Hours show actual development work investment sprint cycle to sprint cycle. Agile teams leverage both metrics in balance – story points to estimate roadmaps and hours to execute iterations.

For example, product owners use story points to sequence business priority stories into multiple release plans spanning months. Development teams break those stories into executable tasks, logging hours on a daily basis to complete specific work items sprint to sprint. Both views help optimize planning and delivery in different, complementary ways.

Setting Realistic Expectations

Any disconnect between story points and development reality get exposed by tracking hours logged against estimates. If completed story point burn rates consistently take more than 20-30% over targeted hours, unrealistic projections likely set wrong expectations.

Hour metrics provide ground truth data to right-size estimating assumptions, lower unreliable velocity rates, and reset achievable expectations. Anchoring estimates and plans to actuals ties roadmaps to empirical trends rather than wishful forecasts.

Communicating the Differences

Developers view backlogs through an hour lens while product managers assess initiatives based on complexity scores. Mismatched lexicons lead to tense exchanges during planning. Collaborative story pointing framed using business value helps teams build shared perspectives.

Additionally, by transparent tracking of both historical metrics in tandem, data conversations replace accusations about inflated estimates or excess time padding. Comparing relative points to actual hours logged builds organizational agility through collective ownership.