our iterative planning
process. We compute velocity by adding up hours, days, or story point
to get a single
number that represents work finished this iteration. The project
can use this to
suggest how much work can be done in the next iteration or sprint. The
team can commit to more or less, but it is a good number to start with.
For our very first iteration we may not have a velocity. If
we did some initial prototypes and measured our progress we can make a
guess, but we don't know yet.
don't break down
velocity by team members because people don't scale, only teams do.
Everyone contributes something different to a team effort. Assuming any
one team member out of a team of 8 will be 12.5% of the capacity is
just plain wrong.
velocity between two teams is also a bad idea. Any two teams will have
different velocities. Consider for example a team moving as fast as
without making mistakes. What happens when you tell them to go faster
like some other team? Take an incredibly productive team that severely
under estimates their work, what happens if you then decide to pay them
less because some other team consistently over estimates? Don't start a
competition to see who has the largest estimates, that is how my table
got to be 14 feet wide.
owner/customer, team members/ developers, and Scrum master/manager all
together to figure out what is feasible in the time that is available.
Product owners don't get every feature, developers don't just work on
interesting things, and managers don't get to tell the team it isn't
doing enough. There are cost and timing trade offs to be made and
getting everyone together to make them is best.
plans are more than just truthful estimations. They are about
realizing that plans have an expiration date. Scrum recommends a month,
Extreme Programming (XP) suggests one week. Be honest about how long a
plan can remain useful and plan on creating a new plan soon.
asked to prioritize a group of features your customer may say
are all needed this iteration or sprint. What you have is a