All About Agile | Agile Development Made Easy!
Agile Planning Meetings - Techniques for getting people involved and staying efficient
Hello All,
We're in rapid change and switching to Agile. We've been noticing some things with our Agile planning meetings (story review and sprint planning) that I wanted to share in case these things are normal or if you had techniques for getting more involvement and speeding them up. Any feedback is appreciated.
Here's our environment:
25 Developers
8 QA
2 Documentation
All team members above are organized in vertical teams
Thanks!
We're in rapid change and switching to Agile. We've been noticing some things with our Agile planning meetings (story review and sprint planning) that I wanted to share in case these things are normal or if you had techniques for getting more involvement and speeding them up. Any feedback is appreciated.
Here's our environment:
25 Developers
8 QA
2 Documentation
All team members above are organized in vertical teams
- During planning meetings not all the team members are engaged and feel these meetings are a waste of their time. For example 3-4 engineers are engaged in figuring out the problem while others act more like chickens then pigs. What are techniques for getting more involvement out of everyone.
- Depending on teams some can take a full day for planning, others take 4 hours. To me a full day of planning for a two week sprint is a little worrisome. Is a full day okay or does it point to other inefficiencies?
- Some teams feel there's too much design going on in the meetings, should a team then take on a "spike" and time-box it to discover more for the next round of planning?
- Team members moral when it comes to planning goes down. How can you make these meetings more fun for everyone? Any games and/or tips?
Thanks!
Views: 193
Replies to This Discussion
-
Permalink Reply by Sina Jazayeri on -
If you have not read "A Practical Guide to Distributed Scrum" http://www.amazon.co.uk/Practical-Guide-Distributed-Scrum/dp/013704... I would recommend it; Chapter 4 discusses a very useful technique "preplanning meeting" in preparation for the Sprint Planning meeting; It's more work for the PO but paves the way for a more effective Sprint Meeting.
-
Permalink Reply by Jeff Holman on
-
Can you give me some highlights of the Chapter so I can get an idea?
-
Permalink Reply by Ilja Preuß on -
Have you taken a look at Planning Poker? Makes estimation more fun and faster, typically.
-
Permalink Reply by Jeff Holman on
-
Yes, we do that. One of the problems is there's to much design discussion going on in the meetings, which usually only involves a couple of core developers and lacks involvement from the rest of the group dragging things on. Here's some guidance I gave the teams, if anyone has anything to add to this please do so:
------------------------------------------------------------------
User Stories:
* As an Agile team WE WANT our planning meetings to be as efficient as possible and well defined SO THAT we're not spending so much time and are engaging the entire team in the process.
* As an Agile team WE WANT to finish out every story on our sprint SO THAT we can find good team rhythm, deliver consistantly, become better at estimating, and enforce accountablity within the team.
These are common problem areas amongst Agile teams as we ramp up. Here are some ways a team can try and satisfy the User Stories above.
1. Have a story review pre-planning meeting
* Get a small focus group together with the PM BEFORE the User Story Estimating meeting to get more clarification on the PM's needs and put together some design concepts for the entire team to discuss. This is not an estimating or decision making meeting, it is only a discussion about possibilities!
* Communicate with Team Members that this focus group does not own the final decision on what gets done, this is still controlled by the team at the story review meeting.
2. Timebox your conversations during the story review meeting around the problem you're trying to solve .
* When the team is discussing an existing or future issue, bug, or research task timebox the discussion, for instance at 2 minutes. At the end of 2 minutes, ask people to vote even if the problem is not understood by all the team members. When the team holds up their weights, chances are you'll have one or more team members that understand the problem and others who have no clue and are showing large weights. Ask the team member(s) with the high weights to explain what they don't understand, so you can get more clarification around their concerns, questions, etc. and then start the timer again. At the end of another 2 minutes, stop the team and have them re-vote. You should see the team getting closer to normalizing around a number. Continue doing this until you get a weight the team feels comfortable committing to.
* If the team is unable to normalize and weights vary accross the board the team does not understand what they're trying to do/estimate and it should be taken off the backlog until it's better understood. In this case assign a "spike" task to someone and timebox it, say 4 hours, so it gives someone a chance to investiage what it is the team is supposed to build and how. Then they can present their findings to the team and weight it for the current sprint if there's room or prioritize it for the next sprint.
* Teams can also prototype an idea if it's not understood as well. In Agile this is called a "tracer bullet"
* If you find that your team continues to estimate after a few rounds STOP the discussion and define a goal for what it is you CAN do. You don't have to understand 100% of the solution up front to get something going.
* Here's a good resource: http://www.gettingagile.com/2007/10/22/research-spikes-tracer-bulle...
3. End the meeting with the teams' COMMITMENT
* When a teams commits to the sprint this means they feel comfortable that they will complete all the items estimated WITHOUT deferring them to the next sprint unless there is really good reason to do so. In Agile deadlines come every two weeks, not just twice a year so teams have to be very aware of what it is they're committing to. If the team over commits, deferring should not be the way out; instead a team may need to put in extra time to deliver what they said they were going to do. One way to make sure all team members agree to the commitment and given a chance to speak their mind is using the "Fist of Five" approach. At the end of the planning session, or after each story explanation and estimation, ask for a Fist of Five Vote. On the count of 3 have team members reflect the level of commitment they're being asked to give by holding up fingers. Here's what they're vote will represent:
o Five fingers: I love this idea. I wish I had thought of it myself.
o Four fingers: I'm happy with this idea and am glad we came up with it.
o Three fingers: I can live with and support this idea. (This is the definition of consensus).
o Two fingers: I have reservations about this and would have trouble supporting it.
o One finger: I have grave misgivings. I can neither live with it nor support it.
*Then, everyone looks around to see if anyone is holding up one or two fingers. If so, these are the people the team needs to hear. Because everyone "votes" from their conscience at the same time, team members are not swayed by others votes. In this way, "Fist of Five" often surfaces unheard voices and helps neutralize conversation dominators *Source: http://www.agilejournal.com/articles/columns/column-articles/888-un...
NOTE: If you notice your team is deferring Stories/Tasks they've committed to from one sprint to the next this should be a red flag. Your team is over-committing, and is not enforcing accountability amongst one another by not finishing. ScrumMasters need to be sure they're making the team aware of this and push for more commitment from the team to meet the time line; otherwise projects will slip.
-
Permalink Reply by Simon Kiteley on -
Up to point one: Something like “We want planning meetings to be as efficient as possible. Engaging the entire team so we can become better at estimation and get greater team ownership” as what you have written sounds a but “you're crap, do better”.
Point 1) Would strongly advise against this is respect to the design concepts. Though you say the focus group does not own the final decision you can bet they will feel they do. In the meeting you have all the knowledge and a possible solution will be identified quickly.
Point 2) You want them to stop having drawn out conversations but then you give instruction on how to have a long drawn out discussion.
Take a story from back log... then vote straight away. If everyone agrees... no point discussing anything. If they disagree get significantly high or low voters to explain why. Vote again... 9/10 times everyone will agree!
If its still far out then what you say about needing to understand the problem better is correct... but why are you taking it off the backlog? Doesn't the story still need to be done!
Point 3) You say you do estimation poker and hopefully you know your velocity so you just need to fill the time box with stories using the two number. Doing the fist thing just seems to be more wasted time.
Your NOTE: “If you notice your team is deferring Stories/Tasks they've committed to from one sprint to the next” you should adjust your velocity.
-
Permalink Reply by Simon Kiteley on
-
If 3-4 engineers are discussing a problem and many more are wasting their time then stop them, do your planning poker and move on. The story will have a high effort to identify the risk but that is fine.
Don't let the teams take 4hr to a whole day. Make it 1hr and be inflexible with it... put it at 11 if you have lunch at 12 or 4pm on a Friday. By restricting the time they won't want to get into these long drawn out conversations.
For a new project, not actually sure what's going on, planning meeting half a day is OK. But once things are going I would only expect to have 1hr to show the stack holders what we have achieved and then a second hour planning the next iteration. (And we'd usually be finished in 40mins)
Not sure it points at inefficiencies but a lack of discipline in meetings. Planning meeting are for planning and that's it.
You could take on a "spike" or you could implement and solution and refactor later if it needs it. The whole
Research, Spikes, Tracer Bullets thing does seem to smell of over complicating things.
Planning morale is down because you are not planning... so plan don't design. Got backlog, get your stories, play your estimation poker, move on... its fun enough.
© 2012 Created by Kelly Waters.
