This morning I met with a new team that has asked me to help them put some process around how they plan, manage and commit to work. This was our second meeting and the team is completely new to agile practices and techniques, so we started by shaping some of their work into features and breaking those features into tasks.

I met with the team’s manager and three of its members (the early adopters). The work in question was conceived by the manager and meant to directly benefit the end users of a system already in development. Our exercise entailed:

  1. shaping a piece of work into features,
  2. breaking those features into tasks,
  3. estimating the tasks,
  4. guessing at the average velocity for an individual team member, and
  5. using the identified estimates and velocity to predict the duration of this work.

This exercise was meant as a practical demonstration of several techniques in the process. We used work the team plans to start in the next week. Our intention is for the team to begin week-long task cycles for just this work at the next meeting.

The team seemed to quickly understand how features, tasks, effort days, and velocity operated and interoperated. (When demonstrating these concepts with real work they often come of as common sense.) The real surprise, however, arose from the decisions the manager had to make and communicate in order for the team to define and estimate tasks. We were not talking about a lot of work here—about a month for two people–but there were a lot of not-so-little details that needed to be communicated and decided. Probably the biggest not-so-little detail was the answer to this question: When would the users actually use what we were building? There were two possible answers to this question: (1) to avoid a processing error and (2) to troubleshoot a processing error. We worked through this to an answer. Then we had to add an analysis task to get an additional level of detail on some of the requirements. Then the tasks to do the work. Then a user-review task.

The team members walked out of the meeting confident they knew the work that needed to be done and that they had adequately communicated to their manager (via estimated tasks) the extent and size of the work. The manager walked out of the meeting confident that the team members understood the work he was asking for and had a coherent plan (estimated tasks) to deliver that work.

If this meeting had not taken place–and I would argue that on many teams it rarely does take place–the manager would have handed this work to the team without sufficiently forming or communicating his vision of how it would be used. The unknowns in the requirements would not have been identified early and taken to the users for clarification. The team would have committed to complete (or would have been directed to complete) the work without a true understanding of its scope or size. The odds would very much be against the manager getting what he wanted when he wanted it.

This team has yet to plan even one iterative cycle, but it has already benefited from expressing the work as discrete features and breaking those features into tasks. These activities have helped the team to design at a high level, plan at a low level, and drive out questions and assumptions about the work. These activities have made the implicit explicit. All in a one hour meeting.

Leave a Reply

*
To prove that you're not a bot, enter this code
Anti-Spam Image