By Henri Stegehuis
About a year ago, I had been struggling with an important "don’t" of Agile Scrum, actual hours. In the first phase of Sprint planning we take all of our actual hours based activities and transform them to ideal hours. The focus factor or productivity factor transforms the hours for these activities to the desired ideal hours. After this initial process actual hours are expelled from current Sprint.
It may take up to a couple of Sprints to get the team really used to the ideal hours way of thinking. Once they understand and have experienced that removing slack from the estimated hours is compensated by using the productivity factor and that the team has control over this productivity factor, this Agile Scrum concept is in place. During the first few weeks as a ScrumMaster you will find yourself pleased with how planning and estimating are addressed in Scrum.
Then reality is catching on
My company’s biggest assets are we, the employees. We offer software solutions; we offer knowledge and broad experience. It all comes down to selling hours and accounting for them. With fixed price projects this problem is easy to overcome by assigning invoice schemes to Sprint deliveries. However, with non-fixed price projects, the accounting is mostly hourly based.
Potentially, the accounting problem with our contractors could be solved by defining certain effort milestones. There is a third party that is really a tough nut to crack, and we need them instead of them needing us, the government. A lot of innovative projects are subject to subsidies. Every claim for a subsidy has to be accounted for based on actually spent hours. The Burndown chart gives no information, as it is intended to, about actual hours spent on a task. For Agile Scrum the past is not interesting but the future is, can we make it in time? Accountancy for contractors or subsidies though lies in the past.
How to integrate
This has kept me busy for a while. I need actual hours, but I don’t want to track them; it is just for accounting. Also, the team must never get the feeling of being micromanaged. Equally important, upper management may not see these hours; I just spent weeks getting them familiarized with ideal hours and the Burndown chart. I don’t want to give them a reason to return to using old methodologies.
The first approach we tried was having the team write down the actual hours once a week on a separate list. This was not working for two reasons. One, the relation with the real tasks became loosely coupled. If I ever had to explain myself on an audit I wouldn’t be able to do so. Two, there were two lists and the team members became irritated. They demanded a solution on the Scrum Board.
Because we would like to maintain a one-to-one relation between Scrum Tasks and actual tasks, we decided to use the Tasks cards. We used the back of the sticky notes to write down actuals information. At the end of the Sprint, I would take down the Scrum Board, and fill the role of Project Manager by administrating the actuals. The consistency was in place and the administrative actions for recording were relatively easy and outside scope of the team and upper management. The recording at the end of a Sprint, when the result was already in place, was so late that the actuals gave no up-to-date, controllable information.
Unfortunately this solution was not working for the team at all, again for two reasons. One, mixing ideal and actual hours in during the Daily Scrum was making people schizophrenic. Two, the other reason might seem over-sensitive, but turning over the sticky-notes was an annoyance, especially while we already had to tape down the sticky notes because they do not seem to really stick (we would always find a couple of them on the floor the next day).
The last approach though had given us valuable input. While we had to tape down the task cards any way, we didn’t have to use the sticky notes. We have decided to make task cards with a default layout. We still use different colors for non-default tasks. Three-fourths of the new task cards is reserved for the Sprint data and one-fourth with a background pattern is reserved for actual recording. In the morning Daily Scrum, we discuss ideal hours, and before we go home, we write down actual hours for that day.
Conclusion
In recent Agile Scrum projects the layout of the Task cards has changed mostly because of the team’s personal tastes. The concept has not changed and the team agrees with the current solution. We know actuals and ideals are conflicting, and it is not Agile Scrum. Now, we separate them by having a different background on the Task cards, and speaking ideal hours the entire day and accounting for actual hours at the end of the day.. We feel that we have found the best solution to secure our sources of income and still follow the Agile Scrum methodology.
