Preplanning Poker: Is This Story Even Possible?

The story says "attach an e-commerce server."

Well, maybe it says "As a product manager I want my system to incorporate an ecommerce server so that I can collect money."

Can you get that done this iteration? It sounds like a three-story-point effort to me, right?

Hold On A Second

This story doesn't have a plot. It is a state of being. I don't think that  saying "once upon a time there was a little girl" would qualify me as a story teller. 

Right away I'm nervous. What the heck does it mean? What do we want to do here? 

Let's not throw this into the sprint backlog with (of all things) a story point number on it. Let's certainly not stick somebody's name on it. Let's think a little. 

We're not aligned on what this "story" means. 

The New Preplanning Poker

You already know about planning poker, and the benefits of silently estimating first, then comparing results. You know that it helps avoid anchoring and arguing and lets you see the degree of separation in estimates in the team. It's a nice consensus-seeking idea. 

I think we need to apply that concept forward to pre-planning (and to non-estimating teams). We will need five cards for this new preplanning poker, as follows:

• Defer 
• Accept 
• Reject 
• Explore
• Split

The astute among you might notice that the acronym for this set of cards accidentally spells DARES. I guess that's okay if we're trying to determine whether we dare tackle this feature as given.

All you really need is five index cards per person and a marker, but if you really want something you can cut and print, try these (font is bubblegum sans):

So here is the story. Pick one of the cards, don't show its face. Ready? One... two.. three

Your answers

You picked defer. Why is this not a good time to add this feature? Why is later better? Is there something far more important to do? Too few developers and testers available this week? Is it scheduling? Availability of people? Is there a dependency such that it would be very hard now, but another feature will soon finish after which this one is easy to complete? 

You picked accept. You think that this task is very well-defined and the criteria for success are obvious. You're ready to go, and you know how to do the work. I'm shocked, given the nature of the story but tell us what you know and what inspires your enthusiasm.

You picked reject. You don't think that the system needs an eCommerce system? Why? Do you have another way you'd rather we received money? Do you think this system should not receive money? Do you think that we should use this system in a way other than a money-gathering device? Why should we never do this? 

You picked explore. You think it's a good idea, and we should get involved, but you believe that there are technical issues involved that we don't understand. Is it platforms? Licensing? APIs? Languages? Authorization/Authentication issues? Architectural concerns? Dependencies? What do we need to know in order to move forward?  I think you are likely right - this may not be something you simply bolt on without some exploration of vendors and technologies and market segments. 

You picked split. That means that this story is not really scoped well. Maybe it needs to be rewritten as a series of stories, or a series of releases, so that each increment of this feature will be well-understood and can be tested and possibly documented. In this case, I agree with you. We might need to know who needs to pay, and for what, and what the flow is around each payment scenario. Each point of payment will likely need several stories to cover all the ways it can succeed or fail.

Will It Work?

I have played this game without cards at a few client sites. Sometimes I'm surprised at how vague a story can seem to me, but be perfectly clear to the local development team. Other times I'm surprised in the opposite way. 

We have had great story mapping and story splitting sessions result from these quick 5-way triage games (is that a quintage?) It takes only minutes and you can get a lot of focused discussion and backlog grooming done in a very short time. 

If you try it out, let me know how it worked for you.

Microtesting TDD: A Quick Checklist

Quick pointers:

1. See each test fail at least once (so you can trust it).
2. Make test fail messages helpful because they fail when you are working on something else.
3. Prioritize!
4. Use a list for tests you want to write. "Ignored" tests will do nicely.
5. Run all the tests so you know when your last change has broken something.
6. Keep your feedback loop as tight as you possibly can.

I get to see these all violated, so I thought I'd make a short list and save you some time. 

The first two go together. You want each test to fail so you can see the message. Some time in the future you'll make a change, and an older test will fail and you'll see the test class name, the test name, and the assert message. Those three should work together so that you know what kind of mistake you made. 

That goes with number 5, too. If you only run the one test you're working on, you may have dozens of breakages by the time you get around to running all the tests. If you work on a component team (not my favorite organization, but sometimes necessary) then you should run all the component's tests at least.  The more "distance" between the injection of an error and its detection as an error, the harder it is to isolate and reproduce and fix. That's why #6 is listed. 

That leaves 3 and 4, which are about planning your steps. You might find some power in the idea of a list. Start by thinking, and create a list of tests you want to write. Then pick which one you want to do next based on what is either simpler or most important. When you think of new tests, add them to the list. When you find some tests are no longer important or describe cases that are already covered, you drop them. I learned this by watching Kent Beck's TDD videos.

If I was to shorten the list, I would say: 

1. Write short tests with great messages
2. Track and the next small steps you intend to take.
3. Keep safe by running all tests frequently. 

That's short, but not as actionable. In the long 6-step form, it's a little easier to take on.

Your Transition Isn't Very Agile

Agile's teaching of "thin, vertical slices" doesn't apply just to features.

Organizations move forward in thin vertical slices too.

Story mapping teaches us to do incremental, value-first programming and integrate the "threads of functions" all the time from end-to-end. 

CI teaches us that integrating thin slices frequently avoids pre-release integration nightmares (and post-release nightmares). 

Likewise, we leave room for learning and growing, because what we learn in iteration N may give us different options and opportunities in iteration N+1 and onward. We have an idea of where we want to go, but we are always seeking best value.

However, too few agile transitions are done in an agile way.

It's only reasonable that a pre-agile company would want a waterfall, Big-Design-Up-Front plan with staffing and milestones for an agile transition. But we, as post-transition coaches and consultants know better and are supposed to be giving advice and support.

And just when we're building software, building a transition in bottom-up, architecture-first, isolated, horizontal layers causes a lot of integration problems.

We shouldn't act surprised.