Level of Effort (LOE) is Not Duration or CapacityLet’s say you are reviewing Task 1 with your analyst:
Lead: How long will this task take you to do? Analyst: Two days.Many people stop here. They have successfully obtained the Level of Effort (LOE) which they can plug into their plan. But the conversation should continue:
Lead: Are there any dependencies to complete this task? Analyst: Yes. When I am halfway done I will need the other analyst to complete Task 2 before I can proceed. Lead: I see she will be taking about a day to complete Task 2. Given that, it looks like it will be 3 days to complete the work from start to finish.Now you have the Duration. The remaining question is: Do you have the Capacity?
Understand the Team’s ObligationsI once had a conversation with a team I had just joined. They were complaining about being overworked, and more being piled on. This was preventing them from doing normal sprint activities, such as reviewing tasks for the upcoming sprints. We decided the best way to prove this to management was to identify all of the tasks they were responsible for on a regular basis, and estimate how much time it was taking from their capacity to take on new work. We discovered the following:
- Sprint Meetings - The team (a QA team) was responsible for supporting different scrum teams, each with their own set of meetings. A 15-minute meeting means at least 30 minutes of your time if you take the time to save what you are doing, quick-prep for the meeting, and finally get your mind back to the original task. Assuming a two-week sprint, with 10 daily scrums at 30 minutes each (due to the time lost per meeting), plus four hours of other sprint meetings (planning, audits, closeout), this is about a day and a half of lost sprint capacity per person.
- More Meetings! - Every manager has meetings with their teams. Company obligations, events, and training can also pull the analyst away from sprint tasks. It adda up.
- Bug Verification - As this was a QA team, they had a constant stream of bugs being fixed during the sprint. While many were anticipated during the planning, a good number were passed to the team unexpectedly. We determined that each bug would take an average of an hour to verify, and based on history, we were able to determine about how many to expect for each sprint.
- Bug Rejects! - This turned out to be our biggest pain point. By pulling ticket history we discovered a large percentage of bugs went through multiple rounds of rejections. By taking this percentage and multiplying it by the average number of bugs, we were able to determine a more realistic number of bugs the team was reviewing each sprint.
Capacity Changes DailyThe hardest thing about capacity is that it literally changes on a daily basis. As you progress in the sprint, more and more things will impact your team. The capacity you had on day one is most definitely not the same capacity you have the last few days of the sprint:
- Design changes occur, adding overhead to the original tasks
- Bugs are found and need attention
- Dependent tasks are completed and trigger new tasks, features are delivered; i.e. everything needs attention at once!
- Priorities change
- Sh...stuff happens!