Posts

Showing posts from October, 2014

Preplanning Poker: Is This Story Even Possible?

Image
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 av...

Microtesting TDD: A Quick Checklist

Quick pointers: See each test fail at least once (so you can trust it). Make test fail messages helpful because they fail when you are working on something else. Prioritize! Use a list for tests you want to write. "Ignored" tests will do nicely. Run all the tests so you know when your last change has broken something. 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 ...

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 ...