Ever wondered why some projects, despite having huge budgets and resources allocated, seem to go nowhere while others succeed on a much smaller scale? The answer could lie partially in a word: Communication.
Rammohan Jayaraman, why innovation! Senior Consultant and Agile coach shares the key communication challenges in business and IT collaboration, and how user stories are central to address these issues.
Common communication challenges between business and IT
During the course of a project, commonly reported challenges include over-specification, lack of shared understanding, differing perspectives, predictive mindset and missing user involvement.
Before a project commences, business users tend to construct a thick set of requirements documentation as the new system's base criteria. The most common way of drafting a traditional specification document is through use cases templates. This usually bulky template comprises primary and secondary factors, preconditions, and success scenarios.
When this documentation is presented to the developers, their first thought is that it covers all the needed functionality and there isn’t more that can be added. It doesn’t help as the sheer size and volume of the used cases compound the problem of developers understanding the full requirements.
Unfortunately, the problem occurs when requirements change or increase, also known as “scope creep”, as the developers may have understood the scope differently. Furthermore, by creating a silo between developers and business users, the communication gap widens. As more of these instances happen, developers start to perceive that documentation is a complete waste of their time. It further increases the gap between the code and the documentation.
When developers are overwhelmed, it prevents any useful conversation from happening before and during the project.
“We need to have clear user stories from the product owner even before the refinement sessions!” is a common refrain you’ll hear from these poor souls.
What is a user story?
In an agile team context, a user story is a document that captures a wish list of features written from the end user’s perspective. A user story can be created using the 3 C approach - Card, Conversation, Confirmation.
The first step is to list the desired features through Cards, which leads to Conversation among the different stakeholders to derive solutions. The goal is to achieve a shared understanding between them, and this agreement can be recorded in a set of Confirmation tests. Using this framework, there is an opportunity to address any misunderstanding right before the project has started.
Let's look at this classic scenario that shows the lack of shared understanding by Jeff Patton with Peter Economy from their book called ‘User story mapping.’ A customer calls a cake shop to place an order. The shop employee asks if he wants a message to be written on the cake. The customer says, "So long Alicia in purple, and put stars around it." But the result was not what the customer wanted at all.
To further dissect what happened in project terms:
A customer and cake shop employee had a conversation, which resulted in the message or “documentation”. This was passed on to the cake decorator. The documentation process worked perfectly and there was clear communication.
So why did the customer still not get what he wanted?
Before we answer that, let’s look at how common such misunderstandings are and what people can do to avoid it.
Many may not realise that shared documentation does not confirm shared understanding which can lead to no user adoption. A 2015 study of 2000 projects in 1000 companies reported that about 45% of features developed through enterprise software systems end up not being used. Imagine that!
With the user story as a key solution, one way to avoid misunderstanding is to evaluate the quality of the story with the I.N.V.E.S.T. principle:
• Independent, in the sense that each use case presents distinct business values critical for project success
• Negotiable, where the question of “If this fails, what else can we do?” should be answered
• Valuable, where the use case’s business value is easily recognisable
• Estimable, which helps in accurately sizing requirements and resources
• Small, where user stories can be completed within a sprint
• Testable, where each member uses the same way to assess whether a user story has been completed
In short, you may share a document with someone but do not assume both of you understood the document in the same way. The best option is to have a guided discussion around the document. There are real-life software development scenarios where, despite sufficiently detailed documentation, in reality, it wasn't enough for developers to build and deliver quality products.
Solutions: How user stories help to bridge the gap
Managing how both sides visualise a problem is key, which is exactly what is lacking in software development and between IT and business perspectives. The fact is, how developers view a requirement is entirely different from how business users visualise it.
One example would be defining a right-sized requirement. The developers would say it takes a few days to build and test. From the business perspective, the "right size" should have a bundle of features that delivers and achieves the business outcome, which surely takes more than a few days to build and test. In short, this differing perspective between business and IT creates a gap that needs to be addressed. Otherwise, a blame game resulting from a miscommunication between business and IT can erupt.
In summary, for user stories, there's a useful and easy template to start with:
As a user role, I want goal, So that benefit
Challenges faced: Commonly asked questions
One of the common issues that crop up during the adoption of user stories between IT and business users is having too many stories that could lead to misalignment.
Unlike other types of projects, software development is not about looking for prediction by applying the industrial paradigm. The requirement conceptualisation suffers a lot from the predictive mindset, which leads to a single-piece flow approach. This applies to business and IT, where both sides are aligned in the predictive mindset.
This alignment actually does more harm than good as it doesn't encourage both sides to be more adaptive. Being predictive enables business users to write a complete definition of the whole system when broken down into smaller parts to build incrementally.
A predictive mindset may create a wall between business and IT users.
For instance, business users may ask if the developer can accommodate some changes into the development. The developer may be unwilling to adapt as the environment has been proven to be change-resistant. The reverse is also probably true. When the developer explains an issue or constraint in development, such as a software version upgrade resulting in rewriting the code, business users may not understand the issue entirely.
In a typical development cycle, there is a three-phase approach that includes elicitation, specification, and validation. Users are involved primarily in the elicitation as well as validation phases. The requirements are gathered during the elicitation phase and a system is developed based on this elicitation.
This model creates three silos - the end-user, the business user, and the IT professional who develops the software. As a result, an illusion is created:
• Developers will know precisely what to build,
• testers will know exactly what to test, and
• customers will get exactly what they asked for.
It is a serialised approach that doesn't allow business and IT users to come together and deliberate over issues and solutions.
Bridging the communication barrier is paramount to project success
Crafting a user story that addresses the project's unique challenges and requirements requires business and IT users to have frequent, meaningful conversations throughout. The power of the user story is how it enables the conversation with two key parameters – the value of the story for the user and the alignment of specification prioritisation between business and IT users.
Without this level of communication, it leaves the details open to interpretation and the potential for misunderstanding and delays, or other undesirable outcomes is high.