Digital Transformation — Agile Methodology — The Story Points Dilemma

Neeraj Arora, Senior Director, Program Management

Of late, agile philosophy and methodologies have been gaining traction for bringing digital transformation journeys to life. However, there are certain aspects that require further debate to ensure their widespread adoption and continued relevance to the changing times.

Transformation and agility are two sides of any digital program that aims to prepare contemporary businesses to thrive in the digital age. Therefore, it’s imperative for organizations to understand, adapt and embrace agile not just as a delivery methodology but as a mindset that can turn a vision into reality.

True, there are countless advisers ready to help organizations adopt agile in their programs. But very few have the capability to use agile methodologies in programs effectively, which helps in achieving the digital program objectives while staying within the program budgets. There are numerous examples of digital programs going astray for a variety of reasons with clueless people blaming their failure on issues with agile methodologies.

This brings us to an important question. Is there a simple way for businesses to determine the relative complexity of functional features, without spending tons of effort in estimating and then apply the lens of business benefit to each feature to determine its development priority? The answer lies in the agile concept of story points. However, it’s not easy as there are several perspectives to consider and contexts to apply.

While talking about story points, there are two distinct frames worth considering. First, the lens of a product owner, or business organization. Second, the lens of the development team (the service/consulting organization) tasked with building the desired platform/features. Often, these two different perspectives are combined into a single narrative, which ends up painting a picture that’s not only difficult to understand but even tougher to practice.

Let’s examine each perspective in more detail.

Product owners/managers representing business interests would gain from understanding the relative complexity of different features on their digital platforms with the objectives of:

1. Prioritizing the features in their digital product road map
2. Budgeting for product development
3. Doing a Cost-Benefit analysis of new features to help with prioritization

Often, we see business teams doing feature sizing based purely on perceived business benefits from each feature. It’s worth noting that the story points attached to each feature are relative to each other and in the absence of a commonly understood metric, vary across product owners and companies. Each organization needs to do a relative story point assessment of features it intends to build into their digital platforms (marketing/sales/service or a combination thereof). At a feature level, these story points are then shared with the development team from the services organization for effort estimation. This will provide the budgetary guidance and help product owners prioritize the roadmap, depending on the budget available.

Looking at the story points from the development team’s perspective, the key is to be able to understand the functionality of each feature, the associated complexity and estimate for the effort required for development. This is critical, as the effort will determine the number of features that can be included in a release timeframe for each team.

Various techniques can help the team conduct a relative estimation of the features. However, agile practioners do not recommend an effort assessment at the feature level in terms of hours and days. Instead, they recommend a relative sizing of the development effort in terms of story points based on complexity and team skills. Several techniques can help with this estimation of relative sizing: planning poker, T-Shirt sizing, Fibonacci series, etc.

Some key aspects to keep in mind:

• The entire team is involved in doing relative size-based estimates
• Each team does its own estimates, which can’t be compared with similar teams
• Each team determines its own velocity in each sprint and aims to improve with each sprint

Key advantages of this technique:

• The team works collectively and takes collective ownership of the work to be done during a sprint
• Saves time by avoiding detailed and specific task-based effort estimates and can get to implementation faster by doing a relative sizing
• Over a period of time, each team gets a fair idea of their velocity and commits to improving its velocity with each sprint
• Brings in predictability with respect to amount of work/number of features that can be delivered in a sprint/release

Challenges associated with a sizing-based approach, independent of effort measurement:

• Doing a budget assessment for a digital program based on story points: Most digital platforms build major functional releases, where scope and timelines are fixed. They are tied to well-defined business objectives and are expected to have a fixed budget allocated upfront. For service companies to do that, effort-based estimation is much more reliable and accurate than any size-based estimate at this point of time.
• Sizing the team to deliver the project in a given timeline: It’s extremely difficult to size the team for a program with a fixed scope and timelines, based purely on story points, in the absence of consistently understood productivity metrics qualifying a story point.
• Unable to compare the size of 2 similar programs based on story points: The biggest challenge preventing the widespread adoption of story points is each team doing its own measurement without any co-relation to other teams.

So we see how these two perspectives, driven by different interests (business benefits vs story complexity) create a conflict. A story with high story points based on business benefit may not have the same high proportion of story points based on complexity and vice-versa. Since business teams and development teams use story points in different ways, a common understanding of story points has been difficult to achieve and thus the adoption of the concept remains low.

Finally, for story points estimation methodology to deliver its intended benefits, the following hold the key to teams achieving the desired level of success:

• Business teams need to rely on story sizing based on effort and complexity, carried out by their development teams. They should use that as an input to determine relative business benefit and the priority order. They must not carry out an independent sizing purely on business benefit as that doesn’t serve the organization’s overall purpose.
• For programs with fixed scope such as setting up an initial commerce or marketing platform as an MVP, businesses are better off using traditional effort-based estimates, rather than relative story-point based estimates to get a clearer picture of time and associated costs.
• For digital programs involving ongoing evolution and enhancement involving high uncertainty around potential benefits, agile methodologies such as scrum, Kanban and story- points based estimation work best. That’s because these provide relative story-size based estimates without much effort and enable quick decision-making regarding prioritizing features based on associated story points and their perceived benefits.

Surely, the industry has adopted agile methodologies in a big way. Traditional IT Services and Consulting companies like Accenture, IBM, Infosys, TCS and Digital agencies like Publicis Sapient are leveraging these on digital programs across industries. Digital native companies such as Facebook, WhatsApp and Amazon are also leading the large scale adoption of agile methodologies and story-points based estimation, helping build trust in the concept.

It’s only a matter of time before a well-understood definition of story points evolves, one that’s consistently used by both groups. What better way to evolve the methodology than by following the methodology itself. Go, agile!