Introduction
The essential aspects of software engineering project are the use of several agile software development techniques to improve the quality and the productivity of the software. Scrum is one such significant method that has greatly been used in the recent years to control the process of software development. According to Cohn (2010), we cannot change or improve what we cannot measure. With Scrum metrics, we can be able to measure and improve the software development process more effectively and efficiently.
Scrum is defined as an iterative agile method of software development that can be used to manage and control the product development process. Scrum provides a supple product development strategy that fosters on team work to achieve a common goal or objective (Sutherland & Schwaber, 2007). Additionally, Scrum can be defined as a basic framework for collaboration in any efficient team that is working on complex software products.
Since the Scrum method is a controlled management process, various tools such as Burndown Charts, Team Velocity and Story points are essential. These tools are aimed at assisting in the maintenance of high energy states to achieve the highest productivity in a team. The use of scrum metrics such as employee happiness, velocity variance, backlog delivery, operational software, unit test coverage and most importantly the cross Functionality of the team. These methods are elaborated in the following sections. Scrum has great importance to the software development process since it enhances team productivity and the quality of the product hence leading the team towards a better project development (Schwaber, 2007).
Scrum metrics
One of the most popular frameworks used for implementation of agile software development is the Scrum metrics. There are several other ways of implementing agile but the Scrum framework has unique features and flavors that affords most teams an incredible way to get started with agile. One characteristic of scrum projects and developments is that they are iterative in nature and involves delivery of products and end results by self-organized teams (Saddington, 2012).
The series of fixed-length iterations referred to as sprints, gives the teams a framework for shipping software regularly. Each iteration has an end which brings a sense of accomplishment to the team for some progress with each cycle. Additionally, short iterations have a tendency to reinforce the value of good estimation and quick feedback. The agile software development lifecycle provides the scrum metrics mentioned above that must be used well to measure the organizational productivity (Javdani, Zulzalil, Ghani & Parizi, 2013). Through the tracking and sharing of sound agile metrics such as Scrum metrics, the organization greatly reduces confusion and focuses on the progress of the team throughout the project cycle (Jaydani et al, 2013).
Although scrum metrics defines several milestones such as sprint planning, sprint review, daily standup, sprint retrospective and backlog grooming; these alone cannot provide guarantees for progress and success. However, it allows the team members the opportunity to inspect and adapt how and what they work on. For this reason, each organization intending to adopt scrum should consider metrics. These scrum metrics can be classified into four categories to allow normalization across all scrum teams for effective organization productivity. These include efficiency, collaboration, effectiveness and quality (Sutherland & Schwaber, 2007).
Classification of scrum metrics
Efficiency: This is a tactical category of scrum metrics that aims at measuring how well the scrum team can deliver value of the product and minimize distractions. The scrum metrics used in this category include the team velocity that measures the amount of work done by the team per sprint that is tracked over many sprints. Velocity variance is another recently proposed metric that looks at the schedule and trend over sprints from the committed velocity to the actual velocity. This is aimed at ensuring that the team can accurately estimate the work and commit to regular routines until completion (Sutherland & Schwaber, 2007).
Collaboration: scrum teams will definitely be geographically distributed but could be working on the same project. This category focuses on ensuring that the teams are able to collaborate despite the geographical distribution. Eventually, all waste is eliminated that could result from computer-collaborated software tools. Some of the metrics used in this category include the process improvement that introduces and modifies tools and processes for increased transparency, continuous improvement and avoidance of reworks. The other metric is cycle time evaluation which focuses on product backlog (Sutherland & Schwaber, 2007).
Effectiveness: the category mainly focuses on business-value generation. Here the focus shifts from efficiency to include how the metric features provide stability, monetization and increased engagement across all the target markets. Value delivery is one important metric in this category (Sutherland & Schwaber, 2007).
Quality: as the sprints evolve, the quality of the product must be determined. This category focuses on determining this quality of the product produced. The product quality is determined or evaluated at several levels of the project cycle. Metrics that are used in this category are those at the individual and test case level. Others include metrics to evaluate acceleration trap (Sutherland & Schwaber, 2007).
How to use scrum metrics to optimize software development and delivery
Scrum metrics mainly focus on the delivery of software products by helping the development team to better understand the software development process hence making the process easier and efficient (Schwaber, 2007). These metric options are discussed below;
Sprint Burn down
In this type of metric, the scrum teams organize activities in the software development project into units referred to as sprints. As each sprint is initiates, the team determines the amount of work that the team can complete during that sprint. The sprint burndown report is then tasked with tracking the completion of work throughout the sprint. The best way of performing this measuring is to use a chart where the x-axis represents time while the x-axis represents the amount of work left to complete. The amount of work left is measured in either in hours or story points. The main goal of sprint burn down metric is to have all the forecasted work completed by the completion of the sprint (Schwaber, 2007).
During the burndown metric, it is important to watch out for the following patterns in the development process (Schwaber, 2007);
The team may subsequently complete sprints early due to lack of enough work commitment.
The burndown chart may show steep drops as opposed to a more gradual burndown due to lack of granular break down of work activities.
The team may miss their forecast sprint due to too much work commitment.
The product owner may decide to change or add new scope and instruction in the midst of a sprint.
Team velocity
Team velocity is basically the average amount of work that any scrum team can complete during a sprint. It is also measured in hours or in story points. This metric is very useful in forecasting and determination of future prospects. The owner of a software project or organization can use team velocity to determine how fast the team can work through the backlog. Since the team velocity report tracks the completed and forecasted work over several iterations; the forecast is more accurate with more iteration (Schwaber, 2007).
It is good practice to closely monitor evolution of team velocity over time. With optimization of relationships and work process a new team can expect an increase in team velocity. On the other hand existing teams can track their velocity to ensure consistency in performance over time. Additionally, the existing team can determine whether a particular change in process has had any improvements or not. Essentially, a decrease in average velocity is usually an indication that a certain part of the scrum team is inefficient and needs to be addressed in the next retrospective (Cohn, 2010).
The team should be keen on the velocity and observer the behavior, they should mainly watch for patterns that could cause significant effects to the project cycle. For instance, if the velocity is erratic for a prolonged period, the team should revisit their estimation practices. The team should often ask themselves the following questions (Cohn, 2010);
Do unforeseen developments and challenges exist that were not accounted for during the estimation of the work? And how can the team better break down the work to unearth some of these challenges?
Is the team any external business pressure to perform beyond its limits? And is adherence to best practices of development being jeopardized as a result?
Is the team too focused on forecasting for the sprint?
With these fundamental questions, we are able to understand that each team’s velocity is unique and the difference does not necessarily mean that one team has a higher throughput. Each team has a unique estimation culture so is the velocity. It is also important to avoid comparing velocity across teams; we should rather measure the level of output and effort base on the team’s unique interpretation of story points (Cohn, 2010).
Control charts
A control chart basically focuses on the individual issues cycle time which is the time taken for a process to be complete. Scrum teams have benefited from optimized cycle times which are a primary metric in most scrum teams. A team with a shorter cycle time is likely to possess a higher throughput while a team with a consistent cycle time across several issues is more predictable in work delivery. Measuring the cycle time is a more efficient and flexible way of improving the process of a team. This is because we can almost immediately discern the results of changes, thus allowing the team to make adjustments forthwith. Ultimately, the goal is to have a short and consistent cycle time (Schwaber, 2007).
In this measuring technique we should scrutinize the trends and not the outright look of the control charts. To do this we will have to be vigilant of two areas (Schwaber, 2007);
Erratic cycle time; the team should be keen to have a consistent cycle time for identified work items that have similar story points. The control chart should be filtered for each story point value for consistency purposes. Should the cycle time be erratic on the large and small story point values, the team should take time in retrospective to determine the misses and improve future estimation (Schwaber, 2007).
Increasing cycle time; increasing cycle time drains the hard gained agility of the team. To avoid this, it is important to take time an d understand an increase. However, there is an exception that if the definition of done (completion) has expanded, the cycle time will also increase or expand.
Team enthusiasm or happiness
Team enthusiasm or happiness is one major component for the success of a scrum team. When the members of a team are not enthusiastic or happy, there is no methodology or process that will work. Team enthusiasm or happiness can effectively be measured through observation of various sprint meetings attended by the team members. It can also be done straightforward by asking the team members whether they feel happy or motivated enough (Cohn, 2010).
Communication
It is important that the product owner, the scrum team, the scrum master, customers and all stakeholders conduct an honest and open communication. We can get clues and indications of how well each of these individuals is communicating by simply observing and listening. Success of the team and the efficient completion of tasks within a sprint are also determined by how well the team members can communicate with one another. Basically, communication is the fabric that forms and keeps a team together (Cohn, 2010).
Cross functionality of team
With a cross functional team, the scrum unit will definitely work as a team with more ease. The elimination of inflexibilities caused by different skills and knowledge enables the team members to work together with more understanding. Members of a cross-functional team will often take on tasks that are not specific to their roles. This demonstrates the depth and breadth of their skill. These are often referred to as T-shaped Talent. The cross functionality of a team is a metric that allows one to assess the cross-functionality of each team member (Cohn, 2010).
Cross-functionality can be measured before and after every project and allow the members of a team to rate one another. The rating can be measured on a scale of 1 to 5 or 1 to 10 depending on the magnitude and nature of the project (Cohn, 2010).
Backlog delivery
Backlog delivery should be handled with great care and maturity and ensure that the items that have more business value are prioritized and delivered first. Mature team members know that they might have to sacrifice time and other resources to deliver this. To help the scrum team achieve backlog delivery, the project owner should separate the important aspects of the project from the most important ones and prioritize that accordingly (Schwaber, 2007).
If the product owner has effective prioritization skills the team will definitely have effective backlog delivery. If stakeholders are left out of the prioritization loop, they will keep wondering why some features were delivered and others have not been delivered (Schwaber, 2007).
Backlog delivery is measured by asking the team members to informally score how often the product owner delivers a fully prioritized back log that satisfies the stakeholders. This can be scored between 1 and 5 (Schwaber, 2007).
The high performing team members own the quality of their own software.
Operational software
The ultimate measure of a successful metric is the eventual delivery of operational software. Scrum team are congregated or assembled to develop and deliver a successful, consistent and predictable delivery of working software (Schwaber, 2007).
Conclusion
Scrum metrics is an agile software development process that offers very lean concepts that are easy to understand. On the contrary these metric concepts could be difficult to implement. It is therefore important to note that in order to successfully implement scrum metrics an organization should think of factors that will contribute to both productivity loss and gain and then implement the appropriate metrics. Additionally, measures should be put in place to relate these metrics to the business context.
References
Cohn, M. (2010). Succeeding with agile: software development using Scrum. Pearson Education.
Javdani, T., Zulzalil, H., Ghani, A. A. A., Sultan, A. B. M., & Parizi, R. M. (2013). On the current measurement practices in agile software development.arXiv preprint arXiv:1301.5964.
Saddington, P. (2012). The Agile Pocket Guide: A Quick Start to Making Your Business Agile Using Scrum and Beyond. John Wiley & Sons.
Schwaber, K. (2007). The enterprise and scrum. Microsoft Press.
Sutherland, J., & Schwaber, K. (2007). A brief introduction to scrum. The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process, 11-15.
