Archive for August, 2009|Monthly archive page

A Post About Kaizen in Which I Get Preachy, or, There -is- a “Try”

Scott says (9:41 AM):so a guy is on a cruise ship

Scott says (9:42 AM):and they cruise near this island in the middle of the ocean and he’s on the deck looking out at the view, and sees a haggard man on the island in tattered clothes running around and waving his arms frantically

Scott says (9:43 AM): and he goes to the captain and tells him about it, and the captain says “yeah, I don’t know what’s up with that guy. we cruise by here every month and he’s always out there doing that”

Scott C. Reynolds told me this joke this morning and it really made me think.

A lot of times development teams have this problem.  They are blind to the fact that something could be better.  We have many times when something will get screwed up or be done poorly and no one fixes it.  There are a number of reasons people will do this…laziness, unwillingness to learn, general blindness.  But maybe it is because they don’t know that there is a better way to do something.

One thing I’ve taken away from this past year of change is the philosophy of kaizen.  “Kaizen is a Japanese word adopted into English referring to a philosophy or practices focusing on continuous improvement in manufacturing activities, all business activities, or even all aspects of life, depending on interpretation and usage.” (Thanks, Wikipedia!)  In everything I do I tell myself that I will do it better than I did yesterday but not as well as I will do it tomorrow.  By doing this, by absolutely drilling it into my brain until it is part of my unconscious, I am ensuring the most quality in everything I do.  If my stories aren’t comprehensive enough and my acceptance criteria not robust enough, I am sure to deeply interpret the next thing I have to write and make it more thorough.

This is how everyone should live.

Software will never be perfect, I will never be perfect, and change is a constant.  These are all truths.  If you can fully ingratiate the notion of kaizen into your life and try to make improvements on everything you do, you’re gold.  You can’t expect to write flawless code every day, but you should expect yourself to see how you made those bugs and why you made them and figure out how to fix that in the future.  If you are thrashing with something, do a little more research on it.  Work a little harder.  Anything you can do to make yourself better, to make your products better, is never a bad thing.

Here’s a thing: broken window theory.  The gist is that if a building in a bad neighborhood has a broken window and it’s left alone, that building is more likely to get vandalized worse because the perception is that it doesn’t matter.  You can find these buildings all over the place in DC in the area of the 9:30 Club (that’s all I can picture when I think of this theory).  These people leave one broken window, and then people start tagging.  And then they break more windows.  And then they have bonfires and pee in it.  Et cetera et cetera.  But say someone boards up that window before the crap happens.  It looks like someone cares.  Maybe it still gets a little graffiti, or maybe people don’t mess with it because someone lives there or otherwise uses that building.

Get it?

Don’t just let bad code sit.  Do the Boy Scout thing.  Leave the campsite a little cleaner than when you found it.  Don’t keep making the same mistakes and letting QA catch them and then do wasteful rework.  Figure out a better solution for what you are doing, talk to someone else who knows it, read blogs.  Do SOMETHING.  Stagnation is the death of everything; do not let yourself become stagnant.  Start improving today.

Maybe this sounds hard.  Well, no one said it would be easy, least of all me.

Do a little introspection and take a look at the way you work.  What are your problems?  What is holding you back from being the platonic ideal of yourself?  Why does your code keep getting kicked back from QA?  If you just pick one thing at a time and lock it into your brain to do, you’ll be there in no time.  Making too many changes at once is a sure way to fail.  Your body and mind are sensitive and need time to adjust; if you want to quit smoking and lose 30 pounds and move to a new place, you’re gonna need to space those things out.  You will fail at one of them.  If you do not, you are a freak of nature and should be burned at the stake (I’m speaking to one person in particular).  The rest of you, don’t feel so bad.  There’s always room for improvement.

Plays Well With Others: Communicate or Die Trying.

So you’ve written some clear and concise user stories with robust and clean acceptance criteria.  Good job.

You’re not done.

Because user stories are placeholders for conversation, simply writing them (no matter how fancy and thorough they are) is not enough.  You need to follow through and talk with your team about what the stories entail.  On our team, Wednesday is Demo Day.  We do a demo of what has been developed so far for our major project, go through screens that have been designed to make sure everyone agrees with the design and functionality (and to make sure they understand what needs to be built), and go through the next MMF to be developed.  At this stage people can interject with additional acceptance criteria that are needed, any concerns they have for the legality or complexity of the system, or anything else they need to voice about the upcoming work.  It’s a great way to make sure everyone is on the same page and have a pretty good understanding as a team about the project as a whole, but even that is not enough.

Last weekend I was emailing back and forth with one of our developers regarding a particular story…the story was fairly confusing, partially because of the way it was written and partially because it is just a confusing piece of functionality.  In the end (after maybe a dozen emails) we realized we needed a higher bandwidth conversation and input from others to really get this story locked in.  When demo time came on Wednesday I found out another developer had taken and worked on the story by himself and the one I had spoken with had not ended up working on it at all.  As the demo went on it became apparent that the entire thing was completely wrong.  Several days of development time had now been lost on this project and we would have to scrap all of that functionality and start over.  This is waste.  Waste is the enemy, to be sacrificed on the altar of agile on the betrayer moon.  Appropriate communication between myself and the team could have avoided this, and this example will serve as a lesson in the future (I hope).

Communication is really the key to everything.  Software development has gotten so good and improved so much because of all of the communication that happens now.  Think about how effective pair programming and user stories are as opposed to one dev holing up in a room with a use case and cranking something out.  Being able to communicate effectively will improve your team and your product, make releases go smoother, and in general keep your life together.  In the past year I have had to make a lot of changes to my life and improving my communication skills (inside and outside of work) has been the best thing I’ve ever done.  If you are thrashing and can’t seem to find a good place to start making improvements, I strongly suggest taking a look at how you communicate and seeing how you can improve that.

Tallahassee Code Camp


I will be speaking at Tallahassee Code Camp ( on September 5, 2009.  I told them I was going to speak about constructing effective user stories, but this is what I’m really going to do:

I may also talk about software, but I am not taking those shoes off.

Hope to see you there!


Acceptance Criteria: Won’t Save You From the Zombie Apocalypse, But Still Useful

Acceptance criteria are a very important part of user stories. While the story itself tells you what a user needs, the acceptance criteria give it context. You get the business need and a set of statements describing the customer’s expectations so that you can better ensure their acceptance of the final product.

So, let’s take that Jaws example again.

As an oceanographer I need to cut open this shark so that I can see if that little Kintner boy is inside.

One of my developers might just rush through to work on this and cut it open right there on the dock. THAT IS A FAIL. That is not the time or the place to perform some kind of a half-assed autopsy on a fish… And I’m not going to stand here and see that thing cut open and see that little Kintner boy spill out all over the dock.

Maybe you give it a little clarification.

As an oceanographer I need to cut open this shark so that I can see if that little Kintner boy is inside.

-do not cut open on dock

Huzzah! Some specification! Now when the developers come to me to talk about this story and complain about having to drag a two-ton fish elsewhere to clean the license plates out of it, I can tell them why it’s a bad idea to rush into this one. To look at this from an actual software perspective and stop talking about sharks for five damned minutes, let’s look at this example:

As a lab clerk I need to be able to add a referring physician to a case so that the diagnostic results can be sent to all appropriate parties.
– user should be able to select referring physician from a list of physicians associated with the account
– user should be able to add new if physician is not available

This is pretty good acceptance criteria. The story is clear enough, saying that they need to be able to add a referring physician to the case, but the acceptance criteria specify how they get that referring physician. There is going to be a list of physicians associated with the account, so a user can choose from there. If we made them type it in each time, it would be hella wasteful and a poor use of their time. Choosing from a list dramatically speeds up their process and avoids QA issues later when they’ve typed the name incorrectly (all. the. time.). But what if the physician is not on the list, you ask? Why, the user can add a new one! Fantastic. The lab clerk can now quickly add a referring physician to this case without a) stopping to have someone add a new physician in the database or b) manually entering physician data for each physician they want to add.

Now this acceptance criteria has given us something very valuable: testability. With more context to this story, our QA team has more to verify and more scenarios to run through. They know that they need to test whether or not there is a list of physicians associated with an account, that a user can select one from that list, that a user can add a new one, and that a new physician added should be automatically associated with that account to appear in the list later (by virtue of being added in line to that case which belonged to that account). We have given this story context and testability, and I don’t think developers would have any problems building this story out. Additionally, the developers will be able to write better tests for the story as they are developing it. It gives the developers a benchmark to hit before they pass a story off as code complete. Testability is really an overloaded term that includes “benchmarks against which we can test our expectations.”

Now, be careful. Acceptance criteria can get ugly and unwieldy fast. You’ll start specifying things like “user should be able to press button to access report,” “there should be a save button that writes the referring physician to the database,” or “referring physicians should be linked by ID to accounts.” These are classic rookie mistakes. Acceptance criteria should not specify design; it should specify outcome. If there is some very specific design you would like to see, mock it up and attach it to the story. (Balsamiq [] is a great mockup tool.)  The second example of suck that I gave was a classic example of overspecification.  This is something that happens all too often when writing out acceptance criteria.  Read back through your criteria, and if something makes you say “well, DUH,” then it’s just noise and the developers don’t need to see it.  Keep your criteria clean and simple and to the point.  Noise reduces signal.  Noise is bad.  The last example is another mistake that is made all too often; specifying implementation details.  You are writing the story from the POV of a user; leave the implementation details to the developers.  This is not to say that you shouldn’t always leave out implementation details; sometimes things are necessary to make sure everything fits together.  Find the sweet spots between all that crap you want to put in there and the stuff that really needs to be in there.  It takes time, and I am still guilty of all of those things, but practice makes perfect (or so They tell me).

One of the best things that has happened to our acceptance criteria is involving the developers.  When we do team planning the developers and QA team are bound to catch things that I have missed.  You won’t always get everything right off the bat and you might not get it all yourself; collaborating with your team will help to ensure that you’ve caught everything.  Meeting with your team just before time of development to discuss things will make sure that you have all of the requirements correct and that you will have all of the information.  If you meet early on, requirements may change and your customer might decide they want something completely different (all. the. time.).  Specifying close to time of development will ensure that everything is as accurate as it can be, to the knowledge of everyone involved.  It’s perfectly acceptable to see the acceptance criteria grow during all phases of development. New information will surface as the team looks at and implements the story, and new expectations will be set. This is ok, and good, and desired because it means the team is coming together to ensure delivery of quality systems.

What acceptance criteria should not be:

– Design details

– Implementation details

– System language

– Overspecification/noise

What acceptance criteria should be:

– measurable

– testable

– descriptive of outcomes > implementation

– individually realistic and realistic as a group

– expectations (especially for a customer)

Not all of these things will work right for your team. Maybe you need some implementation details in your criteria. Maybe a little system language is necessary. That’s ok. One thing I have learned (and still hate) is: “it depends.” Everything is subjective depending on how your team is, things vary project or project (or even story to story), and it’s an uphill battle to hit the nail on the head every time. Take a deep breath, use your best judgment, and refactor it til it’s good.

Constructing Effective User Stories, or, My User Stories Bring All the Boys to the Yard

User stories are…

And this is where I get stuck.  I’ve been so enveloped in writing user stories for the past year that I seem to have forgotten the basics.  I’ve forgotten how I got to where I am now.  When I started my position as a business analyst, my knowledge with software was…limited, to put it nicely.  I didn’t have a damned clue about what I was doing.  And The Google couldn’t help me either.  Sure, I found some things, but everything I found made me look up something else.  Everything was written a tier or two above where I needed it to be.  I needed a really good starting point to kick me off but everything just skipped over that valley of basic knowledge and into the stuff that people really want to read.

So let me try to start from the beginning.

User stories are meant to capture the essence of the business value of a system, and are written in everyday language.  For example:

As an oceanographer I need to cut open this shark so that I can see if that little Kintner boy is inside.

Ok, this is not a software requirement per se, but I am watching Jaws and it is shark week (love!), so deal with it.  Here is a real user story:

As a nurse I need to be able to set my default location so that I am viewing my preferred data when I log in to the Nursing Station app.

Here is the breakdown of that story, and the basic format for user stories:

As a [role] I need [feature] so that [business value].

The nurse is the user who will be using the Nursing Station app.  She needs the ability to set her default location so that she won’t have to waste time setting or selecting a location upon each login to the app.  The business value implied here is that she won’t be wasting time doing this and can instead get some actual work done fast and not hate on my software for being unusable.

Depending on how long you’ve been writing user stories, you may or may not have learned a very true, key fact: users get in the way.  They don’t know what they want but they will be damned sure to tell you.  You will hate it.  Do not count them out.  Regardless of the way they present themselves, you need to come at it with the mindset to figure out the actual need there.  If they are nagging you for a button or a field to enter a number, determine why they need it.  If they just want it because of the way it looks or for an insignificant value/one that may a) mess with the rest of the software or b) tack a lot of development time on, probably don’t just give into their needs (in the long term they will start yelling about how long it’s taking, and when you throw that “you needed this button” back in their faces they are none too happy).  Figure out why they want what they want, what purpose it serves, and if it works for all of the people who will be using the software.  We don’t write code for edge cases, we make it work with edge cases.

The INVEST model

The INVEST model is the shit.  It is one of the best things I have discovered for improving my user stories.  This blog ( has a really great summary of the INVEST model, which I will expound upon here:

Independent: User stories should be as independent as possible (don’t put something about a link in one story and then separate the link functionality; you’d have a dead link if the sprint wrapped and the complementary story did not get completed)

This is something I have really improved upon in my last year as BusinessCat.

1. Making stories more atomic means less of a chance for things to get tangled up and confused

2. That dead link thing?  Yeah that happens.  Be careful and make sure all of your stories and acceptance criteria are complete.  See my thoughts on MMFs at the end of this beast.

Negotiable: User stories are not a contract; they are reminders for the team to discuss and collaborate to clarify the details near time of development

What a user story really is is a placeholder for a conversation.  We’ve gotten away from writing strict, rigid use cases and into these user stories, which are much better for the way the business world really works.  By writing a user story this way, I am opening up a higher bandwidth conversation.  Instead of a developer just reading what I have and doing it word for word, now we can talk about things and make sure everyone is on the same page and fully understands the business value and the needs of the user.  I like that Kelly specified “near time of development” though; that’s one thing you’ll always find: CHANGE IS A CONSTANT.  Friggin annoying, but it is inevitable.  The closer to development time you talk about something the more likely it is that you’ll have the best information and the most clarity on the item.

“A fundamental lean principle is to delay decisions until the last possible moment so you can make the most informed decision possible.” – Mary Poppendieck, Lean Software Development: An Agile Toolkit

Valuable: User stories should be valuable to the user and written in user language

User stories are user stories.  So put on a user hat and write it.  You should never have anything like this in a story:

“title attribute displaying formatted address when user mouses over”

I got stuck putting this in a story the other day by a higher-up and I was really mad at myself for letting it in there.  Yes, it will tell the developer what to do, but no user would write that.  Leave implementation details to the developer. Describe the desired result, not the implementation.  What it should say is:

“display tooltip when hovering over address”

There is still a little bit of implementation language in this, but it’s an abstraction higher than spelling out the html.   Sometimes you can only refactor so far; I would be happy to leave this in one of our stories.

When I have the conversation with my developers we can talk about this to make sure they understand it, but it’s terrible to have the former in a user story.  If I don’t understand it, I shouldn’t be writing it.  And I am the user.

Estimable: User stories need to be possible to estimate; they need to provide enough information to estimate, without being too detailed

This goes back to stories being atomic.  When we write stories on my team, we make them no larger than 3 days worth of work.  If the developers do not agree that it will take three days or less, it’s time to refactor.  This isn’t ideal for every team, but we have worked to become a sophisticated enough team that we can work like this.  Plus, it’s ideal.  If you have massive stories there is more chance for stuff to get lost or overlooked, things will be harder to test, and general craposity will ensue.  In summation: Yer doin it wrong.

Small: User stories should be small.  Not too small.  But not too big.

See above.  D’oh.  Additionally, don’t be discouraged when you need to refactor your stories a bah-zillion times to get them to be more atomic.  You will not get it right at first (I sure as hell didn’t), and a continuous improvement mindset is an absolute necessity to success. Be willing to give it a go, observe the results, and adjust, as an ongoing process.

Testable: Need to be worded in a way that is testable and not too subjective; must provide clear details of how the user story will be tested

When QA tests, they run through many, many different scenarios.  If your stories are too rigid they won’t necessarily hit all of the possible scenarios and edge cases.  Be sure that you leave the story open enough that people will think about all of the ways the feature will be used.

We recently starting using MMFs (“A minimum marketable feature is the smallest possible set of functionality that, by itself, has value in the marketplace.” – James Shore []), which has helped us immensely with keeping things together and not losing track of things.  It also makes our releases easy peasy and we don’t miss things (dead links?), etc.  If your stories seem to be less cohesive than you would like or you find that things get missed, MMFs might be the right route for you to take and I would recommend using that format (or at the very least checking it out and seeing if it’s for you).

For a little further reading, I would recommend checking out Ron Jeffries’ post on the three C’s: Card, Conversation, Confirmation (  He’s got some great points that he makes better than I could, so if you’re interested in more detail about writing effective user stories that’s a good next stop.