Sprint is a planning unit, keeping it stable during that time allows a pretended piece of mind for the developers from marketing/product ever-changing demands. So it feels anyway. We developers signed up a virtual contract with our product teams saying “we will be Agile enough to allow you to change your mind every 1-3 weeks, but don’t disturb us during that time! We want to work, not wasting our time on talks!”.

Does it make sense to you? Is this the true notion behind Agile? Would it be acceptable for a great business?

Well, it makes sense only if you think that waste is more valuable than your attention. Delaying smart decisions or cutting off bad ones after 2 weeks, 2 days or even 2 minutes is simply counterproductive. If you know that a feature selected for the sprint became a waste due to priority change, why should you move forward with it? why throwing the problem to the other side of the fence: “well, my product team should have been wiser with their priorities. We’ll do it anyway just to teach them a lesson so they won’t do it for next sprint!”

Priorities tend to change. It happens constantly. Don’t panic, be open-minded and make sure your team leaders can handle priority shift. It’s perfectly okay to say no, but make sure it’s a “reasonable no”. If you see it does make sense to move out some features and move in some others, do it with care, offer tradeoffs (“this change might mean we won’t be able to release the version on time, let’s delay it in 2 days”) and make sure motivation passes to your team. Your teammates need to realize that providing organized waste is plain dumb; they also need to trust you doing these changes with full attention, clarifying tradeoffs and setting expectations. Practice your agility!

After bashing prediction systems, claiming that measuring performance of your teammates to predict release dates or personal behavior is inherently wrong, you might deduce that I meant “measuring Actual Hours is pointless”. On the contrary my friend, I believe that tracking Actual Hours is imperative for better planning and cutting off waste.

Translate internal units (Story Points / Ideal Days) into external units (Calendar)

How can you translate a 3 Story Points or 3 Ideal Days to “it will be ready next Tuesday”? By using the actual time it took to perform a task or a feature, you could actually see a correlation between Story Points size (internal to the organization) to the total amount of actual work hours range (external as you can put it on the calendar). For example, you might notice after a few sprints that 3 Story Points (based on latest 5 features), are usually taking 23-28 actual work hours to complete. Assuming you pick a number, say 6, as the amount of “effective” work hours in a single day, such features will translate to 4-5 working days.

Story Points can be translated quickly, based on empirical knowledge, to a range of working days. This will make release dates predication much easier, assisting your Project Manager and your marketing team to communicate it within their roadmap.

Tracking your actual work hours will help you to quickly balance effort in a Sprint

You’re on the first day of the Sprint and you’ve got seven Features (/ User Stories) in your “Not Started” column. You also made sure that your teammates’ availability is updated as some have vacations and some got exams during the sprint.

How can you balance your tasks effort, in hours, between your teammates?

By looking at your actual work hours history, from the example above, you can see that a 3 Story Points feature translates into 23-28 hours of work. You can immediately add to all features worth 3 Story Points one task called “TBD” with 25 (average) hours and assign it to one of your teammates. That way, you can add a “TBD” task to each one of your features, simply by checking their Story Points -> actual work hours range.

Next, you slowly break these big TBD tasks, in each feature, into multiple smaller tasks, each with different owner and estimation, until you see that the effort is balanced between all of your teammates. When your team is mature enough, they can break down their tasks and provide their own estimation at the beginning of the sprint.

Two flows for example:

a. 3 Story Points (range: 23-28 hours) -> 1 task worth 25h for Joe -> 1 task worth 10 for Joe, 1 task worth 5 for Jim and 1 task worth 10 for Annie.

b. 2 Story Points (range: 10-18 hours) -> 1 task worth 14h for Jim -> 1 task worth 10 for Jim and 1 task worth 4 for Annie.

c. [ … until all work effort are balanced by availability and optimal ownership … ]
d. Make sure that your breakdown makes sense in terms of people availability. Make changes if needed.

Summary

Tracking your actual work hours is imperative as it (1) provides a way to translate internal work units to external work units and (2) enable fast estimation of large features. The key is to clearly explain how using internal estimation can help with these goals. Asking your teammates to remain open and honest about their actual effort (versus rough estimation) requires a lot of trust from their side. Don’t break it and don’t use it against them.

p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.