When deciding what to work on for the next release, and estimating timings for each user story (and sub tasks for a given story), do you guys do this in a group or just managers?
For a team size of 10, is this practical?
How long does it take?
asked Sep 19, 2011 at 19:44
-
9Why is your team so big? If you are trying to be Agile, you should probably have two smaller teams instead of one big team. Please explain why 10 people are one team.– S.LottSep 19, 2011 at 19:52
-
1Only reason I'm having 10 working programmers attend a meeting is to announce our IPO or bankruptcy.– JeffOSep 20, 2011 at 0:54
-
No. Software written be more than 3 people gets never released. If you hear about counter examples: These are just alpha or beta versions.– LandeiSep 20, 2011 at 12:17
-
I've worked on a team of about 15 people where we did this. The biggest drawback is that at any point during the meeting you have about 10 people sitting on their hands being bored - and this happens for a few hours every week. But, sometimes splitting up teams will create more trouble and miscommunication. It's not ideal, but it's been done.– MrFoxNov 22, 2012 at 21:03
Add a comment
|
4 Answers
Prioritisation should be done by a single product owner with input from the various stakeholders, including a senior developer who is a stakeholder for the code and as responsible for non-functional requirements as a business stakeholder is for the functional requirements.
Estimation should absolutely be done by the people who will do the work, never by a manager who is under pressure to deliver, however your instinct is correct that more than a half-dozen people will spend hours arguing over this. In an ideal world, you really should break the team down such that there are no less than 4 and no more than 7 on a single team -- 5 is ideal, IMHO.
If this is absolutely not possible, for some reason - and you need to apply 5 whys to that reason before accepting that it is impossible - then a team of 4-5 people should be selected by the team to do estimations on their behalf.
In my opinion, you should NOT do release planning as a team of 10 people. Most likely you will end up with a giant meeting where in any given discussion 6-8 people will feel completely disconnected and bored. Add to that the exhaustion of 3-4 hours being locked in a room together. And consider that if 10 people talk, you have way too much conversation. If they don't talk, you may not get valuable input.
We did something very similar to Joseph's company. Previous release we had 8 engineers and release planning took 2 solid weeks. And it was absolutely brutal. Few hours into each day, I think all of us start trying to speak as little as possible so that the meeting would be over sooner.
This release our team size more than doubled. So we broke up into smaller teams that would take permanent ownership of an area of a product. Each of the smaller teams had a lead. Then we did high-level release planning with just the leads, which went by way faster and more efficiently because now we only had 4 developers in a room. During this time, we identified which team would do what stories and how the product will be divided. Also this gave leads the larger picture of the entire product.
Then each lead went back to his own team and went over the portion of the release that only that team was responsible for. During this time, we filled in some details and assigned story point values.
Lastly, everything was put together and we did one final walkthrough (more of a presentation than discussion) so that everyone on the team knows what's going on with the entire team.
Although we didn't have a full successful release with this method, I do think that release planning overall went by way smoother than before and we got much more out of it. The key was that we never had more than 3-4 developers in any given meeting and everyone's voice was still heard.
If possible I'd recommend you split your 10 developers into 3 groups. If you can't divide your overall release into 3 mostly-non-overlapping areas, then even 2 groups would be better than one large team.
I'm actually part of multiple projects (and multiple teams) as a lead, and there a few that are 10+. On almost all the projects I work on, the release planning is done by the leads and the business analysts. However, in our situation the BAs are not the managers, so the managers don't really participate in the release planning.
Estimation is done by the implementation team, though, and although both parts are separate, they are very much related.
Estimation is how much time a task takes to get done, whereas the release planning is when those tasks get scheduled to be worked on.
Planning should be done according to business concerns, while estimation should be done according to technical concerns. Hence the break up of estimation and planning.
-
4+1 - Planning is done by leads and business, but it is critical that estimation be done by the actual worker bees. Sep 19, 2011 at 21:45
This task is more efficiently done by a manager. In small teams, the roles tend to get mixed up. Everybody is involved in everything. But as your team grows, this becomes unmanageable and roles need to be clearly defined.
As much as I do get the desire to be involve in everything, it's just not productive.
