Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
I often read about Agile development in blogs. It seems that some PM terms are sometimes mentioned with slightly different meanings depending on the context. Could you transcribe from a book (either Agile/non-Agile) the definitions of the following terms?
Thanks.
Not sure if you're looking for metrics used to measure those or just the definitions.
Capacity is best thought of as bandwidth. How much concurrent work can a team do. Larger teams will have more capacity (although typically with diminishing returns as the team gets bigger).
Team availability is how much time team members can devote to the project due to holiday, commitments with other teams, admin they might have to do etc. Low availability (i.e. in cases where a team member is working on more than one project) reduces capacity.
Effort is usually used in context of estimating how long things will take to do. A feature that requires a lot of effort will consume more of your teams capacity.
If you're interested in how we measure some of these things:
In Scrum (an agile framework), story points are used as an estimate of the total effort involved in completing a user story. A story involving a small change by dev but needing a lot of testing might get given 13 points whereas another needing more dev but is easy to test might only be 5 points. Complexity and uncertainty can also influence estimation.
Scrum uses velocity to measure capacity. Velocity is the average number of story points they complete in a sprint (defined time period, usually between 1 - 4 weeks).
We typically don't factor team availability in specifically since velocity is an average anyway (some weeks everyone might be in, some might have a few people out) although if we know we don't have half the team in next sprint, we might agree to commit to less stories.
Another approach used frequently by agile teams is to limit work in progress and measure cycle time (time from work to get from one part of their process to another).
For example, a team might only allow 3 items to be in progress at once (to ensure they don't overload the teams capacity with unfinished work) and measures the average time it takes something to go from the product owner introducing the story to the team to the story getting released into live. This way, when they get asked "how long will it take for this to get done" they can say 10 days (plus or minus two) with 90% confidence.
