So you decided to go ‘Agile’ with your team? Maybe you have read a book or two on Scrum, XP, or something similar. Many of the base ideals of Agile development make intuitive sense, but this idea of “Group Planning/Estimating”… Really? Surely that isn’t going to work with ‘my’ team.
I know this is where I was several months ago. The team I work with has been using a number of Agile concepts for years to get projects done, and doing it quite successfully I might add. I was reading up on Scrum, and intrigued by its simplicity yet didn’t really get the idea of how important group collaboration is to its success right away. I had originally balked at the idea of having Daily Standups (after having them for months now, I realize how wrong I was on this), so the idea of having the whole team get into a room for several hours to “plan” (which includes some estimating) every two weeks (our chosen sprint length) just sounded so inefficient. I mean… isn’t planning/estimating the PM’s job? Including all those people and taking them away from “development time” to plan?
Well, I am here to say that a transition to group planning can be difficult, but once you work through the growing pains, it’s well worth the effort. Don’t short-change yourself by going 1/2 way either. If you are planning for a 2 weeks sprint, and it’s only taking 1/2 hour to complete, you probably aren’t planning as a group, but more just planning individually and meeting for a short time to pick tasks individually for the sprint. Most people I have spoken with or read online say it should take around 2 hours per week in the sprint to complete the planning processes. (4 hours for a two week sprint) This is dependent on the size of the team, complexity of the project, etc… but it’s a good rule of thumb, and one that I have found to be about right given the number of sprints I have been involved with.
There certainly is work that needs to be done prior to the planning meeting, especially by the ScrumMaster and Product Owner, to groom the project backlog as well as ensure the User Stories are in a state ready to be handed to the team. But the process of taking a feature and decomposing it into development tasks (unless most of the features you are building are trivial in nature), should be done by the team as who knows better than the ones who will be doing the work? Picking the tasks as a team, golden. Estimating the work as a team, what better way to ensure all team members have at least a semi-good understanding of the work being committed to? Having a say in this process also breeds ownership by the team and it’s members. They have some ‘skin in the game’ from the planning stages, and that helps set them up for success to meet the goals of the sprint which is great for all involved.
I highly recommend reading Agile Estimating and Planning by Mike Cohn as his book will help you work through the transition to group planning very well.
My next post will cover the ‘Ideal Day’ metric, and how I have found it helps the team size User Stories (features).