26891Re: The Scrum Release Plan Dilemma
- Feb 6, 2008aacockburn wrote:
>We create a backlog of "epic's" with short descriptions. Each epic is
> Personally, I think that you should always have a coarse-
> grained statement of time and content goal (and everyone
> on the team should know it). If you are missing that, then
> it is hard for everyone on the team (including the sponsors)
> to pull in the same direction.
> Does this help you out at all?
prioritized by the product owner, and then each of the teams will "bid"
on how much effort it would take to implement the feature. We use a
generic "complexity point" for each team.
Each release is usually around 12 weeks (with a number of weeks
afterwards for hardware/software wring-out, as well as other subsystems
(the physicists) getting a chance to validate algorithms).
After each team is "full" the scrum teams will work with the product
owner (in this case we use product-owner proxies into a systems
engineering organization because of the size of group). to break the
epics into reasonable sized chunks. Most scrums use a two week
iteration. I suppose if you squint, you could say we have a 1 week task
cycle on top of that.
The stories get planned (allocated to iterations), until the teams
basically considers themselves full. At this point we might prioritize
some of the lower priority stories out of the release all-together. We
write customer acceptance tests for the stories for the upcoming
iteration, and break them down into tasks ( we estimate tasks and
stories in hours, not story points).
During the development the product owner and team work together to
prioritize and adjust the stories associated with the epic based on the
demo's at the end of each of the two week iterations. The general rule
is that we can change the scope and mission of the epic (for future
iterations) as long as we don't exceed the original allotment of effort
for the epic.
So, for example, if we estimated an epic as a "High" (approximately 600
hours), we would allow changes to stories and additions and deletions so
long as we don't exceed 600 hours. If we exceed 600 hours, we have to
go back through the organizational balancing process to get more work
tokens. (typically dropping something off our release plan, not just the
scrum team's backlog.).
I hope this (rather short and terse) description of what we do was
helpful. For larger organizations the biggest problem I have found is
maintaining the sense of commitments. Working software every two weeks
helps, but it isn't a substitute for a little bit of forward thinking on
what you plan to deliver. This is particularly true when there are
other groups that depend on your deliveries to make the product (e.g.
hard tooling in manufacturing, mechanical and electrical design teams, etc).
I suppose the flip answer is that they should all be part of the scrum
team, but it gets a bit impractical. The skills are too diverse, and
the teams would be too large.
- << Previous post in topic Next post in topic >>