One team I’m coaching had members with varying degrees of concern about estimating in story points.  The team had difficulty embracing story points instead of units of time because units of time matched their past experience.  We defined “ideal days” for estimation purposes.  An Ideal Day for our team was defined as 6 productive hours in an 8-hour workday.  The team would define a task for a specific team member who would estimate its work in ideal days.  They could determine how many features to include in a sprint by adding up the estimated ideal days against the length of the sprint.

This approach was pretty good:  The team was able to start using Scrum, plan sprints, use a task board and make serious progress.  Those are big benefits!

Some sprints later we began to notice some negative effects to this approach:

• We were still using time as the basis for estimates even though humans are better at relative size estimates.
• We were writing each tasks with a single, specific person in mind.  This contributed to a perpetuation of engineers going off in a corner to do “their piece” alone.
• To some extent, the tasks, and the availability of specific people to do them, were driving the order of the features implemented, instead of value driving the priorities.

Last retrospective the team pointed out that we were not meeting our goals.  We determined that part of this was the desire to make sure all the ideal days were booked with tasks for every team member.  This caused the focus of our tasks to be far too broad.  We noted many times where someone in the Daily Scrum would report an impediment because some other person had not completed their task.  The words “tracking dependencies” and “critical path” even came up!

In the time between the retrospective and the sprint planning meeting, I conferred with a colleague ScrumMaster about the retrospective.  He drew a one sprint long, mini Gantt chart (Gasp!) on the board showing the separate tasks for one hypothetical feature.   We could see that many times integration of individual’s pieces does not happen till late in the sprint, sometimes too late to expect it to work.  We realized that the focus on tasks was completely de-emphasizing delivery of the stories by the whole team.

Thirty minutes later we began the sprint planning meeting with the following proposed shift in the team’s work agreement:

• Don’t explicitly estimate individual tasks except when needed to clarify them further.
• Don’t explicitly assign a person to individual tasks.
• Do use stories that can be completed within the sprint.
• Do estimate the stories by difficulty, size, risk, etc. relative to each other using story points.
• Do have team members self-assign to each story so they will work together to get that story done.
• Do continue to work on the assigned story even if “your part” is done.
• Do support other stories in the sprint if you have time available.
• Do add or remove tasks as needed to get the story complete by the end of the sprint.
• Do track sprint progress on the burndown chart using the story points of completed stories.

We originally started this team by focusing on estimated tasks.  This got us going in the right direction but, after several sprints, helped push us into old ways.  Separate people waiting on each other is not a team.  Now we have a story focus with the understanding that the tasks are only important as long as the story gets done.

Work the story, not the tasks!  We’ll see how it works for us.  If the team board looks like this at the end of the sprint, it’ll be a success.

http://www.flickr.com/photos/dinomite/ / CC BY-SA 2.0

(I have been looking around the web while thinking and writing about this blog post.  Seems some teams and well known agile leaders don’t agree about estimating only tasks or only stories or both.  For example, Mike Cohn recommends story points for release and backlog planning but time on tasks for sprint planning.  Well, inspect and adapt is the agile way.  We tried only estimating time on tasks for a while and think we don’t like it.  This switch to story points may be what we need.  Or we’ll adapt again later.)

Those familiar with Scrum and XP and other agile practices know about the daily team meeting.  Sometimes called a “daily stand-up,” this is a meeting held every day at the same location and time.  In this 15 minute meeting the team usually stands in front of the team board to discuss three questions, and three questions only:

A Simple Task Board

• What did you get done since the last meeting?
• What will you do before the next meeting?
• Do you have any impediments to your work?

The team board has story and task cards that are moved across to document the progress of each task.  Each team member owns the task he is working and signifies that ownership by moving his task cards in turn as he answers the questions.

So what is the elephant in the room?  In this team’s case, it is the table.  Yep, a simple and useful object that decreases the effectiveness of the daily team meeting.

This team does not have a dedicated team room.  This less than ideal situation is handled by using a task board on wheels that lives in the hall where the team members work for visibility throughout the day.  The board is wheeled into a conference room for the daily team meeting.  The conference room has a table in the middle.  A large one that is difficult to move.

The team board is placed on one side of the room and, due to the limited space directly in front of the board, the team groups on the other side of the room.  With the table in the middle, between the team and the team board.  Suddenly, it is too cumbersome for each team member to come around the table and move their own task cards.  The ScrumMaster stands at the board to move the cards for the team.

List the damage:

• Team disconnected from the task board
• Members disconnected from ownership of their tasks
• The meeting feels and operates like reporting to the ScrumMaster instead of reporting to team peers
• Less energy in the room
• Team is physically divided

Scrum is about people, not technology.  The subtle but real psychological effects cause by the table cut the effectiveness and communication of the team in half, or more.  It seems a small thing, it’s just a table after all.  In physical reality, perhaps it is small.  But the mental and social structure of the team is decimated.

Maybe you can think of more negative effects of this situation.  It’s all bad.  And it’s just a table.

Does your team room or meeting location have such “elephants” in the way?  Are the chairs too inviting?  Is the lighting wrong?  Assess your environment to from the team cohesiveness point of view and eliminate the physical “elephants” that distract your team from the best agile experience possible!