DZone
Agile Zone
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
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Agile Zone > 3x5 Cards: What a Waste!

3x5 Cards: What a Waste!

Jared Richardson user avatar by
Jared Richardson
·
Apr. 20, 10 · Agile Zone · Interview
Like (0)
Save
Tweet
10.95K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Cards (iOS)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • What Is Cloud-Native Architecture?
  • 3 Pieces of Bad Advice on How to Keep Your IT Job
  • Take Control of Your Application Security
  • Top 11 Cloud Platforms for Internet of Things (IoT)

Comments

Agile Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • 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:

DZone.com is powered by 

AnswerHub logo