It has always puzzled me – why, oh why do developers just love combining all requirements for a given individual feature in a single story? A new form? It will be a story. A new checkout logic? Yes, a story. Upsells, downsells, membership offered within a checkout? Yep, just add them all to the same story. So the stories blow up more and more, becoming unmanageable, having all their intricate requirements and test case scenarios woven into the endless paragraphs of text, get moved from sprint to sprint, and eventually get failed and failed again by QA because they can’t approve something that has 127 business rules when even one of them is not working.
Painfully familiar?
But we are PMs! (And POs). We convert pain points into opportunities for growth and providing value to everyone around us, isn’t that true? So, let’s dive into this difficult conversation about The Story, The Dev Team, and how we all made them happy about each other.
Should you still invest in INVEST
We all know the principle. To quickly elaborate on the original idea published in INVEST in Good Stories, and SMART Tasks on XP123, these mean the following:
- I – Independent – Stories are easiest to work with if they to not overlap in concept, and could be schedule and implemented in any order.
- N – Negotiable – It is not an explicit contract; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details
- V – Valuable – framed in a way that makes the customer perceive them as important
- E – Estimable – just enough to help the customer rank and schedule the story’s implementation
- S – Small – typically represent at most a few person-weeks worth of work
- T – Testable – If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.
The whole trend of turning everything into acronyms strikes me as a bit odd. It’s like we brainstormed some principles for how stories should roll, and then someone thought, “Let’s cram it into an acronym so it’s easy to remember, who cares if it actually makes total sense or follows rock-solid logic?” It feels a bit like we’re more focused on creating a catchy abbreviation than ensuring the principles themselves stand on solid ground. This approach seems to prioritize the memorability factor over the actual substance and coherence of the principles. It makes you wonder how effective these acronym-centric frameworks really are in steering us toward meaningful practices that make genuine sense or rooted in undeniable reason.
Now, let’s unravel the INVEST principle and see if it truly holds up to scrutiny.
Debunking INVEST
Independent – Not sure what the technology looked like in 2003, but it’s very often impossible to deliver a complete piece of value within one story that even follows the INVEST principle without overlapping or creating dependencies. Within the last decades, technologies have become incredibly more complex and rarely allow us to release stories that are manageable enough without creating relationships between them, especially when we are working on functionalities that involve complex user processes.
Negotiable – It looks like this description better suits the “Epic” definition. A story has to have details; otherwise, it may not be properly tested. And those details may not, in any way, be a complete reflection of the developer’s view of the requirements. The requirements must come from business validated with customer research. And although the “how” is on the implementation side and belongs to the developers, the “what” must be exactly described in the story details. If it’s not an explicit contract, it will never be a reflection of what the customer needs; it will be its interpretation, which is not good enough. Ideally, the “what” should be described in the story so well that it will be sufficient to perform all necessary testing within the story without creating any additional testing plans.
Valuable – Looking at the “Independent” – according to the same logic, it’s hard to release a single story that would contain independent value. Well, maybe if it’s an addition of a block of text. Even a new text field, added to the existing form, although provides individual value, may require rounds of regression, validation, and integration testing, and sometimes may require the full form restructuring, which may not fit within a single story.
Interestingly, but, the author mentions that developers tend to slice the stories into “layers”, and this defeats the purpose of releasing the complete value. However, we have observed the opposite tendency of developers combining stories and making them too bulky to understand, cover all test case scenarios, or even properly document without losing pieces of requirements in the endless sheets of explanations without any structure inside the Jira “Description” field.
Yes, a full database has little value to the customer, but even completion of the full database may be big enough for the story. Stories may and should be subject to slicing for work optimization, and not because someone had to use the letter V in the word “invest” and didn’t know what meaning to assign to it. And we have to now suffer from this and insist on providing value to the customer by completing a single story…
Estimable – I disagree that the estimation doesn’t have to be exact. A story definitely should be estimable, but if the team wants to have solid planning and accountability, the estimation is better to be as close to exact as possible.
But I absolutely agree that the estimability of a story serves as a crucial indicator of the clarity of its requirements. If a story is challenging to estimate, it often signifies that there might be uncertainties or gaps in understanding certain aspects of the requirements. And I will add to this – the more exact we can estimate the story, the better it indicates the clarity of requirements.
And even the author admits that “bigger stories are harder to estimate.” So, let’s make the stories smaller!
Small – Funny enough, what “small” meant in 2003. It actually represents “at most a few person-weeks worth of work.” And a common sprint is 2-3 weeks. So, basically, according to the author’s logic, a team of developers may work on a single story for two, maybe three sprints? Four? QA is resting meanwhile. How is this agile and an iterative development? The way I see it, the story should be definitely small, but I would repurpose the letter S and convert this “S” stop into “S” – Simple.
The story should be SIMPLE – simple enough to represent as minimum test case scenarios that it would be straightforward, easy, and not involve too many conditional testing. Say, 2-3 test case scenarios at most, in my perfect world – 1 story should represent a single test case scenario. It should be developed and tested in as little as a couple of hours to as long as 2-3 days, quickly tested, and marked as done. Slicing larger stories into smaller ones allows a flow and fast conveyer of story implementation and the testing cycle to crack them done, ensuring their successful unit testing. If there is a need to retest them inside specific user flows, it may be achieved within its own story that, by itself, may contain conditional and scenario testing.
Testable – The problem with large stories that take long to develop and contain multiple business rules, data validation, integration, and multiple scenarios is that the testing strategy blows up to unmanageable proportions, which makes it very easy to miss things. And we all know that even small errors may result in huge losses. How much easier it is to just write a story that contains scenario-related rules, cross-dependent field testing rules, integration requirements, UI requirements; – all of these have different ways of testing, require different mindsets, sometimes even need different devices and different QA skills.
Having endless testing plans (or even worse not having any and needing to come up with them on the go) is extremely heavy on anyone’s mind. Splitting any heavy and complex work into smaller tasks makes it easy, less tiring, which always results in higher efficiency and less chance for error.
So, what would our recommended INVEST would look like? Let’s see if we can reinvent INVEST.
INVEST to VEST
- V – Valuable – framed in a way that provides value independently (we did leverage the I!) or partially represents the value that is delivered by the implementation of a related group of stories.
- E – Estimable – The story estimability servers as clear indicator of the clarity of the requirements, which allows for the estimation to be close to exact.
- S – Simple – The story’s simplicity must be driven by its implementation and testing strategy, where its implementation is absolutely achievable within a single sprint with a one-person effort, and it may be tested using only the development/business requirements and specs provided within the story. Ideally, the story should contain 1-3 testing points/scenarios.
- T – Testable – If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.
Yes, we are dropping the “IN“. Here’s why. Quite often, it’s really hard to release independent value within a single story that will not make your whole team sprint after sprint only to realize that the story is already dated. Or test cases keep arising, and the story can’t get signed off by QA just because it now needs weeks and weeks of all kinds of testing. And by the moment you go live with it, the market changed, and you need to do it all over again. We don’t have to follow this to the letter, especially when the letter doesn’t make sense.
Same with the “negotiable”. I am not even sure why it was there in the first place. A story may be negotiable only on the implementation strategy side. Even testing, commonly representing the customer, must follow the requirements exactly. The test case scenarios absolutely may be created together with the team, but if the requirements are concise and clear, the scenarios are not really needed – everything should be outlined by the requirements and serve as a testing strategy.
Slice your stories
We are finally here, where I have been leading you, my friends, all this way. Whether you are a developer, a Product Manager (Owner), or a Scrum Master, I invite you to embrace the idea of slicing stories into the smallest bites you can still see with your talented and experienced eye. Try to work with these little bites and experience the lightness of this beautiful process.
But worry not; I have got some solid reasons for this irresistible offer. Here they are:
Straightforward Understanding and Clarity
Breaking down stories into smaller, focused units ensures that each story addresses a specific aspect of the functionality, enhancing clarity of the requirements and ultimately their correct implementation.
Easy and Exact Estimation
Smaller stories contribute to easy and exact estimation. Estimation becomes more straightforward when the scope is limited, reducing the chances of overlooking complexities. This, in turn, helps in creating more precise and reliable sprint plans.
Fast Pace Processing
Working on smaller stories promotes a fast-paced development and testing cycle. Team members can complete and deliver smaller units of work within a single sprint, ensuring a quicker pace of progress and continuous delivery of value.
Simple and Fast Testing
Smaller stories lead to more manageable testing scenarios, making testing simpler and faster. Focusing on a specific functionality reduces the risk of overlooking critical test cases, facilitating easier identification and resolution of issues.
Quality Assurance Reinforcement Layer
When individual small stories need to be retested within a specific user process or using cross-dependency business rules or successful integration, this additional testing layer is never redundant. Instead, it ensures quality and gives the team an extra peace of mind about the effectiveness of the working process
Faster and Easier to Get to the Definition of Done
The smaller size of stories makes them faster and easier to get to the definition of done within a single sprint. This ensures that each unit of work is thoroughly completed, tested, and ready for release, contributing to a more efficient and predictable development process.
Unleashing Productivity and Boosting Dopamine
Breaking down stories into smaller ones ensures that team members don’t get overwhelmed by the volume of complex assignments. Completing smaller tasks provides a sense of accomplishment and contributes to higher morale, helping in maintaining focus and motivation throughout the sprint. The more the sense of accomplishment, the higher the spirit! Gotta get that dopamine rolling.
Efficient Utilization of Resources
Smaller stories enable better resource allocation, allowing team members to work on multiple smaller stories concurrently. This ensures a more balanced workload, leading to optimized resource utilization and preventing bottlenecks in the development process.
Improved Adaptability to Changes
Smaller stories enhance the team’s adaptability to changes. Since each story addresses a specific functionality, adjustments can be made more efficiently without affecting the entire development cycle. This aligns with agile principles of responding to change over following a plan, especially when the change is dictated by fluctuations in market demand.
Enhanced Collaboration and Communication
Breaking down stories promotes collaboration, as team members can work more closely on specific features. It also facilitates effective communication within the team, ensuring everyone is on the same page regarding the requirements and progress of each story.
The journey from questioning the amalgamation of requirements into colossal stories to the advocacy of slicing stories into digestible bites has been a pivotal one. The invitation stands to embrace the concept of breaking down stories into the smallest, manageable units. This approach aligns with the core principles of efficiency, clarity, and adaptability, offering a refreshing perspective on agile development.
In this article, the very famous INVEST principle, once hailed as a guiding acronym, undergoes scrutiny and transformation into the VEST framework. The focus shifts to Value, Estimability, Simplicity, and Testability, shedding the unnecessary constraints of being “Independent” and “Negotiable.”
The reasons behind advocating for smaller stories are rooted in enhancing the development process, and isn’t it what we are all striving for? Clarity in the requirements, fast-paced processing, simple and fast testing, and reinforcement layers for quality assurance contribute to an optimized development cycle.
The call to action extends beyond theoretical principles; it’s also about unleashing productivity and boosting team morale. Ultimately, we all want to find joy and accomplishment in completing our work, leading to a higher spirit and a higher probability of accomplishing more work with a greater feeling of reward.
In the grand scheme, the shift from INVEST to VEST and the advocacy for smaller stories contribute to a holistic and efficient development approach, adaptability, simplicity, and collaborative progress in the ever-evolving landscape of agile development. So, let’s break down those stories, savor the smaller bites, and revel in the agility and effectiveness they bring to our development endeavors.
I hope I convinced you to try – just try – slicing your stories, or maybe you are already successful in it. Let me know how it’s working for you. And if you like the new VEST story writing principle.
No responses yet