Project Schedule Management and Cost Management in Agile Context


Relative Estimation in Agile 

Relative estimation in Agile is a technique used by Agile teams to estimate the size or effort required for completing tasks or user stories within a project. The concept is based on the idea of comparing the relative complexity and effort of different tasks rather than providing absolute estimates in terms of time or effort.

Here's how the concept of relative estimation works in Agile:

Relative Size x, 2x,3x, 4x,5x
Relative Size x, 2x,3x, 4x,5x

Teams consider three factors when arriving at relative estimates of effort: 1) the amount of work to do, 2) the complexity of the work, and 3) how much risk and uncertainty is associated with that work.  

Instead of estimating tasks in hours or days, Agile teams use relative units of measurement such as story points. Story points represent a combination of factors including complexity, effort, and risk associated with a particular task.

A baseline story serves as a reference point for comparing the size or effort of other stories within a project. The baseline story is typically one that the team collectively agrees upon and assigns a certain number of story points or other relative units of measurement. It's used as a benchmark for estimating the relative complexity of other stories in the backlog.  Overall, the baseline story plays a crucial role in Agile estimation by providing a common reference point for the team to gauge the size and complexity of user stories within the project backlog.

Team members compare the user story/requirements  with the reference point to gauge its relative size. They might ask questions like, "Is this task more or less complex than that one we completed last sprint?" This comparison helps in assigning appropriate story point values.  

Estimation is typically done collaboratively during Agile ceremonies like sprint planning or backlog refinement. Team members discuss the tasks, share their insights, and collectively arrive at an estimation consensus. This ensures that different perspectives are considered, leading to more accurate estimates. 

Example below shows how to estimate a product back log.

Estimation and capacity planning
Estimation and capacity planning

Based on the data in the above figure :

1 point = 1 day of work, 400 USD in terms of cost estimates

The total size of the product backlog = 30 points.

No of team members = 1

The capacity/Velocity per sprint = 8 points

Estimated No of sprints required to complete the product backlog = 30/8= 4 

Budget per sprint = 8 x 400 =3200

In a similar manner you can calculate the no of sprints and the budget per sprint when the number of team members are 2 or 3.

Planning Poker Method

Planning Poker is an Agile estimation technique for estimating the size or effort of user stories or tasks within a project. It is a collaborative and gamified approach that involves team members collectively estimating the relative complexity of items in the product backlog. Here's how the Planning Poker method typically works: 

Preparation: Before the Planning Poker session, the product backlog should be refined, especially the top level requirement should be detailed appropriately ,  user stories/requirements  should have sufficient detail for team members to understand what is being requested.  The baseline story or stories should be identified as a reference point.  Each member of the development need to hold either physical planning poker cards to use online virtual planning poker cards. 

Poker Cards
Poker Cards

At the start of a poker planning session, the product owner  reads one of the desired user stories or describes a feature to the estimators. Each estimator has a physical or virtual deck of cards. These Planning Poker cards display values like 1, 2, 3, 5, 8, 13, 20, 40 and 100 (the modified Fibonacci sequence). The values represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent their estimate. The estimators then reveal all of their cards at the same time.

If all estimators all selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators, especially, should share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The team repeats the process until they achieve consensus on an estimate. If they lack enough information to agree on an estimate, the estimators can defer a particular item until those details can be acquired.

Affinity Estimation/T Shirt Sizing

The Affinity Estimation Technique, also known as Affinity Grouping or Affinity Mapping, is a collaborative method used in Agile project management for estimating the relative size or effort of user stories, tasks, or items in a backlog. It is particularly useful when dealing with a large number of items that need to be estimated quickly. The technique leverages group consensus and categorization to organize and prioritize backlog items based on their perceived complexity or effort.

Here's how the Affinity Estimation Technique typically works:

  1. Preparation: Before the estimation session, the product backlog should be well-defined and broken down into manageable items, such as user stories or tasks. Each item should have sufficient detail for team members to understand the requirements.

  2. Estimation Session: The team gathers in a collaborative environment, typically during a sprint planning or backlog refinement meeting. The session is facilitated by a Scrum Master or team member.

  3. Grouping: The facilitator presents the backlog items one by one, either verbally or by displaying them visually (e.g., on sticky notes or cards). Team members then group similar items together based on their perceived complexity, effort, or other relevant factors. This grouping process encourages discussion and consensus building among team members.

  4. Labeling: Once the items are grouped, the team labels each group with a category or size range. This could be done using markers, sticky notes, or other visual aids. For example, categories could be "Small," "Medium," "Large," or "Extra Large," or they could use T-shirt sizes (XS, S, M, L, XL).