3x5 Cards: What a Waste!
3x5 Cards: What a Waste!
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
3x5 cards, sometimes Post-It notes, are a mocked, and often ignored, tool. We're an enterprise. We're a real company. We don't use anything as ridiculous as slips of paper! We use enterprise tools. We use databases! By the way, why do we keep having problems with unclear requirements? Why do we constantly argue about when we're "done"? Why do we have problems with constant requirement bloat? Let's think about it.Databases are vital to the enterprise space. Anyone who argues otherwise is overly focused on the team level at the expense of the company. However, when a team lives in the database, it can quickly become a hiding place for all kinds of problems. There are several very common problems that a simple 3x5 card can resolve.
Before we talk about what problems they solve, let's talk about what goes onto a 3x5 card. There are a number of different schools of thought, but I like this format.
- As a ( role)
- I want ( feature or fix )
- So that ( motivation )
- On the back of the card, you write the acceptance criteria.
This simple format solves several major problems. First, it requires a bit of background. Which type of person wants this feature? What is a the feature? And what problem are they trying to solve.
Quite often features tend to be either extensive documents (epics, if you will), and other times just a few words or phrases. Acceptance criteria, when it exists, is often "it works". The 3x5 cards draws out more information, but just information to be useful. At the same time, they prevent you from going into too much detail.
The next time you're starting to work on a feature, take a step back, and create a simple 3x5 card. Find out, before you waste your time coding, if you can answer these simple questions.
- Who needs this work?
- What exactly is it they want?
- What's the motivation?
- How will I know when I'm done?
You don't have to though. You could instead follow one of these scenarios.
Not knowing who wants or needs the feature, you can make a few assumptions about what they need, their technical expertise, and their background. Make some guesses and do your best. History has shown us that developers are pretty bad at this, but don't worry. You're special.
You don't know exactly what the end user requested, but again, no worries. You're a pretty smart person and you can probably just figure this out as well. Just write something that you'd want. You're a fair copy of the end user, right?
Why did they need the feature? You don't really need to know this one either. It's just the motivation behind why the paying customer wants the new feature added. This additional insight might save you time and complexity, but really, if it could be simple, then anyone could code this stuff. Don't worry about targeting the user's needs. Have some fun with this one. And remember, resume driven development rocks!
What about acceptance criteria? Do I really need to know when it's "done"? Well, we know it'll be done by Thursday, since that's the code freeze. We'll just cram in as much as possible in the meantime. Oh, what about when it goes to QA, and they have a different interpretation of what's "done" for this feature? No worries... that's what the code freeze is for... we can rewrite the code to match up with QA's understanding then. It's always better the second time anyway, right?
Enough sarcasm... writing these short cards will save you a great deal of time in the weeks to come. Work with your business analysts (or product owners, or whatever your company calls them) to get the extra information. Find out what the feature really needs to be instead of wasting your development hours coding up the wrong ideas. Co-ordinate with QA to be sure you both agree on what the feature should be when it's "done". If you can't agree, go back to the source of the feature and get more information before you code it. Don't waste tons of time defining the entire product for the next two years, but spend just enough time to define what you need for the next few days. Maybe even the next week or two.
Do 3x5 cards replace your database? No. But they do make a mighty handy tool for your day to day work.
Opinions expressed by DZone contributors are their own.