DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Zombie Stories: Conversations From Beyond the Grave

Zombie Stories: Conversations From Beyond the Grave

User stories are kind of like zombies - if you try to bring them back to life they'll just end up trying to eat you and destroy your world.

$$anonymous$$ user avatar by
$$anonymous$$
CORE ·
Oct. 31, 17 · Opinion
Like (2)
Save
Tweet
Share
5.49K Views

Join the DZone community and get the full member experience.

Join For Free
"That's the thing about zombies. They don't adapt and they don't think." - Max Brooks

One of the earliest challenges I ever had to resolve, as a Scrum Master, was the proper disposal of the dead. The typical situation ran as follows. My team would plan user stories into their Sprint Backlog, and would then work on them during the Sprint. The corresponding value would be invested into the increment. In other words, an increment of release quality would be created, such as would meet the team's Definition of Done, and those planned stories would then be removed from the scope of remaining work.

The problem was that occasionally, as a result of experiences gained by incremental release, some of those stories would be found to be incorrect or otherwise inadequate. This is, of course, entirely to be expected from an agile way-of-working. Each release is an opportunity to inspect and adapt the product. However, it can also create a problem - or at least the perception of one - for a team which has consigned the associated user stories to history. How can those stories then be revised to properly capture the latest understanding, so further work can be done and the product improved? This was the quandary my team found itself in, and they looked to me for a remedy. In short, they wanted me to bring their user stories back from the grave.

What they didn't quite understand, at that point, is that user stories are only "valid" for the Sprint they are developed in. Remember that a user story is a placeholder for conversations about a possible requirement. Those conversations happen during a Sprint in which the story is actioned. Once the time-box is over and the stories retired, the conversation placeholders within it are indeed history.

If a story is found to be "in error" after it has been retired - even if it is just one or two different acceptance criteria which have been identified - then those findings relate to a new story. In other words, we will have a new placeholder for one or more future conversations about the required scope, and the work for this must be estimated and accounted for on the Product Backlog. The new user story might resemble an earlier such placeholder very closely, but it will be a new story nonetheless.

Of course, if the acceptance criteria of the original story were not actually met, then the story was never completed in the first place. It should remain on the Product Backlog with a re-estimate of the work needed to finish it.

Sometimes people can tie themselves in knots about user stories "breaking" when new requirements emerge. The thing to remember is that a user story can't actually break. The conversations will hopefully happen, and the story will either meet its acceptance criteria and satisfy the Definition of Done by the end of the time-box, or it won't. The conversations the story represented during the Sprint cannot break as a result of any future discovery, and so the placeholder itself can't break. None of these old conversations can travel forward out of the past and into a future time-box where they become undone and broken. What will "break" - hopefully - are certain products of that story, such as deprecated regression tests derived from old acceptance criteria.

It's entirely reasonable to suppose that acceptance tests will need to change - just as the system itself needs to change - to accommodate new conversations and new stories that emerge as a result of agile development and delivery. It would not be reasonable, however, to "consider the impact" on old stories. There is no impact. There may be an impact on their products, such as BDD tests that circumscribe old acceptance criteria, but this should be addressed by new stories that consider the system as-is and the work remaining. That is achieved by having new conversations and new stories to represent them.

Old stories are over with, spent, archived off, in the past, and finished. Move on. So don't be tempted to bring a dead story back from the grave - create a new one instead. Happy Halloween!

Conversations (software) Sprint (software development)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Spring Cloud: How To Deal With Microservice Configuration (Part 1)
  • Top Five Tools for AI-based Test Automation
  • AWS Cloud Migration: Best Practices and Pitfalls to Avoid
  • Stream Processing vs. Batch Processing: What to Know

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: