Weathering the storm

One of the common tasks when working in an agile environment is pointing stories, its essential that the team and the product owner get together and decide on how much effort something is going to take. We had a meeting scheduled today at work to do just this, 4 stories that needed pointing so they could be put in the backlog, all pretty straight forward right?

Like all good agile practitioners, we set out some guidelines at the start of the meeting. We would time box each story discussion at 8 minutes and then move on. As well, we decided that each team member would take turns reading one of the stories so that everyone was involved and engaged. We started out well and made some progress but it was obvious that things were coming off the rails, and fast. Team members were getting frustrated, a couple of members were just pointing stories really high because they weren’t understanding the business value that each story conveyed (the product owner was present, and the team had met previously and discussed the stories in a brain storming capacity), the product owner was getting more and more frustrated, the team members quickly lost interest and everyone left the room feeling a bit worse for the participating.

I thought I would highlight some of the issues and try to address them:

History repeating
Some of the team members had worked on implementing the feature that we were pointing in the meeting in a past iteration of the project. The attempt failed costing the team of 3 people a months worth of time. It was obvious that this weighed heavily on those specific members and it was influencing there estimates. Understandably one can be sympathetic of this attitude, failing at the same thing over and over again is demoralizing and soul crushing. The thing is that scrum accounts for failure as long as you learn from it, I think though that this issue is a very difficult one to get past and I can’t really criticize too harshly on the topic.

Breaking the law
After the first story was done and pointed in the time allotted, we quickly ran overtime on the second and it just got worse for each subsequent story. We had completely ignored what we all agreed on at the start of the meeting and it turned a 30 minute exercise into a 90 minute marathon. I think in this case sticking to what we agreed to at the start would have made for a much more satisfying meeting, I think the desire to please the product owner and get the stories point outweighed the obvious fact that we weren’t doing a good job pointing them. I think in retrospect we should have just stopped the meeting and moved onto other work and reconvened another day, it probably would have saved a lot of people a lot of time and energy. This is something to try next time for sure.

A couple of interesting things happened later in the day that this meeting took place, my co-worker Jason Little wrote a blog post talking about this exact topic (I think the meeting had a pretty deep impact on all involved), go check his post out .

The other interesting thing is that I caught a tweet on twitter that stated “storming is the most interesting part of team formation”. This kinda made me think for a second, so I Googled the term and came to this interesting wikipedia page. The really interesting bit for me is the entry on storming:

The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Tolerance of each team member and their differences needs to be emphasized. Without tolerance and patience the team will fail. This phase can become destructive to the team and will lower motivation if allowed to get out of control.

This so quantified the exact feelings I was having about the meeting, it really reassured me that this is a normal process and it eventually leads to bigger and better things. It certainly made me feel much better about the situation and that we can and will progress past that stage onto more productive and fulfilling team situations.