Analytics is the foundation for better agile planning

Agile planning, by nature, is fast and adaptive, with room to make changes as needed. However, a process that’s designed to be flexible can also be influenced by subjective factors, such as the agile team’s own perception of which user stories should take priority.

True objectivity within agile planning is only obtained through the use of data and analytics. Data tells the true story of what’s going on within processes and what the actual outcome of the DevOps work is. Data tells us which features and stories have — and deliver — value, such as improving usability or increasing revenue. Data is the tool used to separate measurable results from guesses.

Without data, there can be a disconnect in whether the work performed generates a positive impact on users and makes progress towards priority business outcomes. Missing data may even lead to priorities being set in an arbitrary fashion. However, once data comes into play, stakeholders throughout the organization — not just in development teams — can scientifically determine answers to these big questions:

1. What features matter most to our users?
2. How can we improve our processes?
3. Are we delivering the maximum value in an efficient way?

Data feedback guides vision and eliminates the sometimes arbitrary nature of the decision-making process.

Here are several examples of how data analytics can be used to improve agile planning and gear it toward better outcomes that produce concrete value:

• Prioritizing user stories
• Using data feedback to inform release planning
• Evaluating sprint performance
• Finding opportunities to optimize processes
• Pivoting quickly to respond to changing needs of the market
• Determining new features that customers need

Prioritizing user stories based on predicted business outcomes

Evaluating all feedback is important. The value that co-creation opportunities can derive from business objectives, such as revenue or product releases, can also come from passive and active user or customer feedback.

• Passive feedback includes metrics like daily active use of certain features and user error reporting.
• Active feedback includes surveys, user complaints, and requests.

Leveraging the data from this feedback creates an objective measure of what user stories have the potential to generate the biggest impact. For example, a combination of user metrics and customer feedback may identify certain platform tasks experiencing high latency that correlate to user bounce. This presents an opportunity to address the latency, cut down on bounce, and improve the customer experience.

Keep in mind that many common methods of user story prioritization are subjective, such as MoSCoW and priority poker. Also, a lot of hefty decisions are left up to the discretion of the product owner or agile teams. While they may have good intentions, if they’re making decisions without data, it’s still just a guess. Intuition can’t be the sole guide to scrum leaders, who want to lean towards the stories that can bring the most benefit. Internal considerations, such as implementation time, might also steer scrum teams away from prioritizing stories that offer the most value.

Using data feedback from service, testing, security, and operations to inform release planning

Applying analytics from other domains is similar to the above use case of prioritizing user stories, but on a bigger scale of release planning. Agile and DevOps teams need data feedback from service, testing, security, and operations. Soliciting this feedback can put important priorities on their release radar. Chasing after the most tantalizing capabilities isn’t enough. You have to have the data to back up your choices.

Data feedback is a critical step of DevOps. It’s part of the figure eight diagram, but it can get overlooked. Development is rarely told to adjust practices or priorities based on operations feedback alone. Yet, this feedback can be vital towards unlocking greater value creation within all stages of work. Data can bring to light critical changes to products and can push important items onto the release schedule.

Reports of vulnerabilities in security testing, for instance, mean that effort should be put towards closing gaps in protection.

Similarly, operations reports generated from analytics that measure change risk can inform development teams about practices that lead to defects or even incidents. Development leaders can leverage data from all key systems of record to root out and address particular practices, teams, individuals, or CI correlations that become sources of change risk.

Evaluating sprint performance and business results

Many agile teams are guided towards anticipated outcomes, but the actual outcome is not always measured. Performance evaluation should be introspective rather than seen as a way to punish poor performance. Teams can ask: “What went right?” and “What can be improved?” instead of just: “What went wrong?”

A good example of an evaluation tool is a burndown chart. This chart shows the work progress within the sprint, based on work milestones. These short work chunks involve specific objectives to finish during the sprint, and the time taken for each milestone to be accomplished is tracked in a visual way, with shorter times depicted as shorter “steps” in the chart.

Generally speaking, you can look at the finished sprint results and say the performance is good or bad, based on whether the objectives were accomplished or not. But a closer look at the burndown chart will paint a more complex picture. Finishing a sprint early means that work between the milestones can be expanded, while missing deadlines can mean that too much work was taken on. Burndown visualizations with steep steps can mean the work wasn’t broken into enough increments. This data is actionable, and it can help you plan a more effective sprint.

Team goals are also key to success. Autonomous teams not only improve productivity, but also foster higher employee engagement.

As a McKinsey & Company article notes, “Successful agile organizations focus on team performance when setting goals and evaluating performance, often allowing teams to define their own goals to drive ownership.”

Scrutinize processes for opportunities to optimize

Organizations need to be able to understand the flow of work, as well as the flow of value through the stages of work. Analysis of this value stream visualization will reveal opportunities to improve processes.

One example capability is achieved by comparing overall lead/cycle time to time spent at specific stages of DevOps. Determining flow time can identify stages in between work where a release sits unfinished, waits for approval, or waits in limbo during handoffs between teams. Some questions to ask include:

• How can we eliminate these “dead spots”?
• Can teams be given pre-approval?
• Can we model changes to be more standard?
• Can we restructure teams, such as putting a security consultant in the scrum team to prevent the need for a separate consult?

Organizations will not only improve their products, but they may find that the processes they take for granted can be improved in an iterative fashion. Data can show bottlenecks in other areas, whether in tools, processes, or people. Recognizing these bottlenecks is also an opportunity to identify cumbersome manual steps and processes and then automate them for greater agility and efficiency.

Moving agile planning into the data age

Agile is a productive mindset, but it can often be at the whim of arbitrary or subjective factors. Software development needs to be data-driven rather than basing it on intuition or judgement.

An example is the use of non-data-based ways to prioritize user stories. These often come from the judgment of the product manager or product owner, based on their knowledge of the market and customers, and can clearly be subjective.

Implementing data into the process not only means developing better products, it can also mean less unnecessary work for teams. Data can drive accountability as well as ownership. Teams with self-service access to analytics can operate autonomously to set objectives, improve processes, and chase better performance.

Agile itself needs agility. Only data can get it there. Otherwise, it’s essentially throwing darts blindfolded and hoping to hit a bullseye.

Learn why using agile only at the team level might be holding back your organization, and what you can do to increase effectiveness and scalability in our eBook: “8 reasons team-level agile isn’t enough”.