In Agile, the software planning process primarily depends upon a single key metric – the development team velocity. Team velocity represents the work done by the development team during a single iteration cycle. It is a changing, and evolving, “average” metric value used often during the software planning process – usually during the sprint planning sessions. The velocity provides an estimate of the team’s current capability to develop product features. The product owner makes extensive use of the velocity metric during the software planning process.
The software planning process occurs in two stages – when the product is initially envisioned by the stakeholders and the entire project is planned and during the sprint planning sessions.
The project release and estimation
Project planning is not an elaborate process in Agile. It commences when the stakeholders or the client envisions a product having a certain monitory significance. The stakeholders convey their idea to the product owner – a person who represents their interests in the project – and instructs him or her to “plan” the project. All the dynamics pertaining to the project are carefully thought about and worked out by the PO and the stakeholders. One of the most important criteria is to estimate in how much time the project is likely to get completed. The PO is required to plan a tentative “release date” i.e. when the project is expected to be completed. Estimation and velocity metrics help the PO to set up a probable release date.
1. Estimation
The PO creates the product backlog, which contains the list of user stories or product backlog items depicting the product features and functionality to be developed during the project. Each user story has a certain business value linked to it. In Agile, only features having high business values are developed so the project can maintain its market worth at all times. Each user story is estimated in the backlog. Depending upon its estimation, each story can be developed within a certain duration by the development team members. Since the team velocity is not available at the project’s onset, the PO assumes an arbitrary value for the velocity metric based upon his or her personal experience.
2. Velocity
Velocity is the rate at which user stories are developed during the daily sprints – the product incremental cycles. The development activity can commence once the product backlog is created. So, the very first sprint may have the velocity as zero on the first day of the first sprint cycle. As development is carried out daily in the sprint, the velocity starts increasing. The final velocity value can be “calculated” once an entire sprint is completed. As sprints keep on progressing and the features keep on being developed, the velocity metric assumes a more realistic value.
The estimation metric indicates how complicated and extensive the project is likely to be. The velocity metric conveys in how much time the team can develop the product. The PO balances these two metrics while providing the project release date.
Sprint planning sessions
In Agile, the product is developed in bits and pieces through the product incremental cycles know as sprints. A sprint has to be “planned” before it can commence. This is done through the sprint planning meeting. During the meeting, the PO selects some of the high priority product backlog items and transfers them to the sprint backlog. This is where the estimation and velocity metrics come in. The PO cannot select the total number of items on a random basis. As per Agile principles, all the product items taken up for development in a sprint have to be completed by the time the sprint gets over. User stories should not remain incomplete at the end of sprints. If the PO misjudges and takes up more stories for development purposes than the team can handle, they are most likely to remain incomplete at the end of sprints. This is not acceptable in Agile.
On the other hand, if the PO selects fewer stories, the team will remain “free” and unoccupied at the far end of the sprint. It means the team is not performing at its full capacity – again not acceptable to Agile.
Therefore, it is important to balance the two factors – pick up enough stories so the team can handle it, and developing the stories in the correct manner so they can become “acceptable” once they are developed. The PO can achieve this balance by “adjusting” both metrics.