The iteration planning meetings are the most important meetings for the iteration to be successful. These are the meetings where the team plans for the work to be done in the upcoming weeks. But somehow I have not heard or read much about how these meetings should be conducted. Most of the books and websites just mention to have two 4 hour sessions for planning meetings. What really happens in these planning meeting seems to be a mystery. I have been a ScrumMaster for a while and have helped teams with planning meetings using various approaches of which some are very effective and some are not.
I wore a traditional project management hat before I was assigned the role of ScrumMaster to one of the projects. The only formal training I had then was that I had read Ken's black book "Agile Software Development with Scrum". As a traditional Project Manager, transitioning into the ScrumMaster role, I sat in the middle of the room projecting and taking notes during the planning meeting. I honestly felt I was helping the team by adding stories, breaking down tasks, assigning hours, etc. The team felt good that they didn't have to worry about entering stories, tasks and hours. However, soon I realized this approach is totally ineffective. This method of planning was very time consuming. The planning meeting took more than 2 sessions of 4hours. And worse of all, not everyone in the team were talking the same language. I could see team members tuning on and off of the conversation. They were only interested in the part that they planned to execute. So I looked back and thought about what was wrong. The problem was me. I was hand holding the team so much so that I became the bottleneck. If I am unavailable the meetings did not happen, the team mates provided scrum updates to me rather than the team. The team looked towards me for guidance and direction. I was still wearing my project management hat and not being an Agile Coach.
Luckily, I was able to get into Ken Schwaber’s “Certified ScrumMaster training” course and I was able to get some advice from him on planning meetings. With the new information I gathered from Ken, I worked on being a coach. I let the team do most of the talking and only got involved when team started getting off track. So what did I do different? My laptop was used for projecting, but only to display the prioritized list of stories from the product backlog. I asked the team to huddle in front of a whiteboard and draw the design on what was implemented so far. Soon it was realized that there were some discrepancies in the way they understood how the system worked. But after some more discussion and clarification everyone in the team was on same page. As a next step, I asked the team to update the old design on the whiteboard to accommodate the new set of stories the team planned to work on. The entire team got engrossed and focused on the design discussion. The development engineers as well as QE engineers were on the same page. The design came out much better. There was a sense of achievement by everyone and most of all, the meeting was productive. Once the design was finalized, I asked team members to select their preferred stories. I helped the team by jotting down stories and assigning stories to team members. I asked the team to work offline on decomposing their assigned stories into granular tasks along with hours needed to accomplish the needed work. The next day we got together for an hour and as a team reviewed every story and task. We made adjustments by adding/deleting and updating the tasks along with hours and we were good to start our sprint. This approach was so effective compared to the earlier approach. The team was self organizing, they were empowered to make decisions and more over it was fun!
I would like to hear other experiences on planning meetings.
1 comments:
Good discussion on this thread can be found at
http://groups.yahoo.com/group/scrumdevelopment/message/41791
Post a Comment