Capacity of a team is the measue of the team's availability for work per iteration.
Most common method of estimating the capacity is:
Capacity = #People x iteration duration x availability factor.
Availability is the fraction of the time that an individual team member can spend, in a given duration. This is also called Focus factor.
As before, point = 1 person-day = 8 person-hours.
Steps to calculate Capacity:
- Determine available time for a team in an iteration (available person-days - overheads)
- Determine people (resources) in the team effectively available for the iteration (excluding PTOs etc)
- Per-person capacity = focus factor * (person-days - PTO)
- Per-team capacity = sum of all per-person capacities
Let's take an example. Let's assume following:
Working days in an iteration = 5
Working hours in an iteration = 40
Hours spent in meetings and stand-ups = 8
Hence,
Net working hours available = 40-8 = 32 hours
Net working days available for the iteration = 32/8 = 4 days
Let's say, there are 5 people in the team.
PersonA's availability factor = 25 %. Hence, PersonA is available for 32*25% = 8 hours
PersonB's availability factor = 50%. Hence, PersonB is available for 32*50% = 16 hours
PersonC's availability factor = 70%. Hence, PersonC is available for 32*70% = 22.4 hours
PersonD's availability factor = 55% Hence, PersonC is available for 32*55% = 17.6 hours
PersonE's availability factor = 60%. Hence, PersonC is available for 32*60% = 19.2 hours
Total of the individual hours = 83.2
Hence:
Total hours available for the team for the iteration = 83.2 hours
Points available = 83.2/8 = 10.4 points.
Team Resources = Team hours / Iteraion hours = 83.2 / 32 = 2.6
Wednesday, December 29, 2010
Task and Story Estimates
There are specific ways to estimate the effort required for a task and story. This is done during the sprint planning meeting.
A task is estimated in terms of person-hours. Note that, it is the effort estimate, and not the estimate of the duration or elapsed time.
A simple way to arrive at an estimate is 'Planning Poker'. Each team member is given a set of poker cards. For a given task, each team member 'votes' for an estimate number, using one poker card in his/her hand. All team members are supposed to vote at the same time, so that, nobody's vote is 'influenced' by someone else's vote. Once all votes are in, the members are required to justify their estimate. A re-voting is done, if required. At some point of time, all estimates 'converge' in a single one.
A Story Estimate (or PB Estimate) is the sum of all the tasks in the story (or Product Backlog). Typically, at the story or PB level, the estimates are expressed as points. So, the sum of the task estimates is divided by 8 (assuming 1 point = 8 person hours). This gives the Story (or PB) Estimate.
A task is estimated in terms of person-hours. Note that, it is the effort estimate, and not the estimate of the duration or elapsed time.
A simple way to arrive at an estimate is 'Planning Poker'. Each team member is given a set of poker cards. For a given task, each team member 'votes' for an estimate number, using one poker card in his/her hand. All team members are supposed to vote at the same time, so that, nobody's vote is 'influenced' by someone else's vote. Once all votes are in, the members are required to justify their estimate. A re-voting is done, if required. At some point of time, all estimates 'converge' in a single one.
A Story Estimate (or PB Estimate) is the sum of all the tasks in the story (or Product Backlog). Typically, at the story or PB level, the estimates are expressed as points. So, the sum of the task estimates is divided by 8 (assuming 1 point = 8 person hours). This gives the Story (or PB) Estimate.
Tuesday, December 28, 2010
Iteration Activities
Apart from daily stand-ups, following are the activities that are performed in an iteration.
- Iteration Planning Meeting
- Task Breakdown and Estimation
- Development and Testing (Actual work)
- Iteration Prep for the next Iteration
- Iteration Review (Demo) Meeting
- Iteration Retrospective Meeting
In general, all meetings are considered overheads, and are not counted while calculating team capacity.
What is Scrum?
Scrum, by definition, is an Agile framework for Software Development.
Key Definitions:
Sprint: Also called Iteration sometimes, it is a pre-defined period of 2 to 4 weeks, during which an incremental and deliveration product is created by the team.
Daily Scrum (or Stand-ups): Daily meetings. They are conducted daily, at the same time, and are very short- typically 15 minutes.
During a daily scrum, each team member specifies 3 things:
- What did he do yesterday?
- What is he planning to do today?
- Any blockers/issues that stop him/her from the planned work.
ScrumMaster is responsible for taking steps in order to 'Unblock' the team members.
ScrumMaster or Iteration Manager: A person who oversees the process and makes sure its smooth flow. He/she often replaces Project Manager.
Product Owner: is the business owner of the project/product.
Pigs and Chicken: These are the two roles. Pigs are the people who actively participate in the daily Scrum activities: meetings, development work etc. ScrumMaster and the Team represent Pig role. Product Owner may also be considered as Pig Role, however, he/she does not participate in the daily stand-ups etc.
Going forward, Sprint and Iteration are used interchangeably.
Story: A story is something to be worked on, during a sprint. A Software requirement or a defect (bug) is a story. A typical story has 3 parts:
- Title
- Short Narrative
- Acceptance Criteria
A story is broken down into smaller pieces called Tasks. A task should be trackable, and should have a clear definition of Done.
Product Backlog: A prioritized set of requirements (stories).
PBI: Each requirement in the Product Backlog is called Product Backlog Item, or simply, PBI.
Sprint Backlog: A prioritized set of tasks to be worked on (and completed) during a sprint.
BurnDown Chart: Graphical representation of amount of work not yet completed, in a sprint.
Done: Acceptance Criteria or Exit Criteria, that determines whether a task (or PBI) is complete.
Examples of Done criteria are:
During a daily scrum, each team member specifies 3 things:
- What did he do yesterday?
- What is he planning to do today?
- Any blockers/issues that stop him/her from the planned work.
ScrumMaster is responsible for taking steps in order to 'Unblock' the team members.
- Title
- Short Narrative
- Acceptance Criteria
A story is broken down into smaller pieces called Tasks. A task should be trackable, and should have a clear definition of Done.
Examples of Done criteria are:
- Code reviewed and Unit-Tested.
- Code checked into a common Code Library (or repository).
- Build Deployed successfully.
- Automated Build Accecptance tests run successfully.
- Regression Tests run successfully.
Velocity: Capacity of work.
The Agile Way
I came across the term 'Agile Methodology ' when I was preparing for a job interview. Till then, I had been using the so-called Waterfall Model of Software Development. However the new job position expected me to work in Agile environment. That's how (and when) I started reading and learning more about the Agile methodology.
Let's look at some basics here.
Agile Methodology differs from Waterfall in the sense of the overall workflow. In Waterfall Model, we specify the scope of a project, and estimate the schedule of the project (Discovery to Delivery). In Agile, we specify the schedule (Duration) of the project, and then estimate (modify) the scope, so as to fit it in the schedule. Also, there is a continuous cycle of Design-Develop-Test-Deliver. We do not wait for one stage to complete, in order to go to the next stage of development.
Basic characteristics of Agile:
- Project is broken down into fixed-length durations called Iterations or sprints. Typical length is 2-4 weeks. Each iteration involves a complete life cycle: Design-Code-Test-Deliver.
- Team is cross-functional and self-organizing. Typically teams are small, size < 10.
- Documentation is very mininal. The teams operate in a face-to-face manner.
- More towards 'Adaptive' side of the spectrum, than predictive.
- More direct and more often interaction with customers.
Let's look at some basics here.
Agile Methodology differs from Waterfall in the sense of the overall workflow. In Waterfall Model, we specify the scope of a project, and estimate the schedule of the project (Discovery to Delivery). In Agile, we specify the schedule (Duration) of the project, and then estimate (modify) the scope, so as to fit it in the schedule. Also, there is a continuous cycle of Design-Develop-Test-Deliver. We do not wait for one stage to complete, in order to go to the next stage of development.
Basic characteristics of Agile:
- Project is broken down into fixed-length durations called Iterations or sprints. Typical length is 2-4 weeks. Each iteration involves a complete life cycle: Design-Code-Test-Deliver.
- Team is cross-functional and self-organizing. Typically teams are small, size < 10.
- Documentation is very mininal. The teams operate in a face-to-face manner.
- More towards 'Adaptive' side of the spectrum, than predictive.
- More direct and more often interaction with customers.
Subscribe to:
Comments (Atom)