User Story Card Clarified, Part 2

Continue from Part 1.

Card

Write user stories on index cards, not in a digital management system such as JIRA.

If a user story (written by a business analyst) is turned redundant or to be included in another one, you tear it off. If one user story seems too abstract, break it into multiple user stories, i.e., tear it off and write it down in several new index cards. You don’t need to log on to JIRA to delete it or drag it to the ‘backlog’. By doing that, some might probably worry about velocity…, etc.

There are other subtle benefits of physical cards. Once a team member finished the task (coding or testing), he stood up and put the card in the next column. This gives him the satisfaction of being ‘Done’ (with a touching sense). By the way, regular stand-ups are good for programmers, as an Apple Watch would tell you.

Q & A

1. Handwriting in physical story cards is hard to read!

Yes, your observation is correct. Unfortunately, most people's handwriting nowadays is quite bad (thanks to the use of computers). The agile board in JIRA does look a lot neater. However, this simple reason is NOT good enough to use JIRA.

In fact, this can be solved easily. I once created a free software StoryWise (now deprecated), which had a feature: printing a user story onto an index card. It is not hard to do.

Summary

A User Story Card aims to foster communication among the software team members, not aiming for detail to perfection. This is in line with the Agile Manifesto.

Instead of wasting a lot of time on the meaningless process, we shall focus on delivering the features to make it available for the customer to try promptly, ideally in hours instead of days or weeks. This is the winning formula.

Expecting 100% perfectly detailed user stories in JIRA and asking developers to code and testers to rigorously test sounds like WaterFall.

In reality,

• customers may not know exactly what they want
• business analysts may misunderstand the customers’ requirements
• business analysts may not write down the customers’ requirements clearly
• developers and testers may understand the text in JIRA wrongly

After all, the application under development could change constantly and rapidly. With that in mind, the whole JIRA game sounds silly, doesn’t it?

“only dead fish go with the flow” — proverb

Some may say: “Yes, that’s the true nature of software development. Does it mean that it is pointless to capture the criteria for the requirement?”

No. Business analysts and customers need to come out with acceptance criteria, but they do not always need to write them down in a text document. Convey the information to SETs (Software Engineer in Test) who can translate the acceptance criteria into one or more automated E2E test scripts. In this way, you will have live specifications if you maintain the tests well (you should if you use CI/CD or CT/DevOps).

My User Story Card looks like this

I still use the format that I learned from the agile coach in 2005. The three colour boxes work as below.

• After BA understood the requirement, he/she coloured the red box.
• After the developer implemented the feature (code and automated E2E tests), he/she coloured the blue box.
• After the on-site customer/manual tester/BA/Manager verified the feature (in the system), he/she coloured the green box.

We encourage conversation among the team members who are working on this user story. The physical card (being carried with them) provides the scope and context for the discussions.

After the green box is filled, the life of this user story ends. It would be put on the storyboard (physical). After the sprint/iteration, ‘green’ story cards will be torn off. No one cares about completed user stories anymore, as they are captured in automated E2E tests.

Some might ask: “What would happen if there is another update to a completed user story?”. Write a new story card for it. Done is Done.

It is important that all automated E2E tests will run in a CT server multiple times a day. Real Agile is simply impossible without s solid E2E test automation & Continuous Testing process.

Further reading:

• Estimating User Story Points is a Waste of Time