Because I’m a consultant, I receive emails with a question, “Do you consult in <fill in this blank>?” Many times I do. But the real question is. “What is your objective?” or “Why do you want to do <this thing>?” There are many good reasons to do so. Release some product—any product, for example! Go […]
Last week at Agile 2010, Joshua Kerievsky and I facilitated an Open Jam session (open space) about what done means. We discussed a variety of points. I believe we eventually agreed that context matters. It’s important to know what your product success criteria are. If you don’t use a project charter where you define success
I spoke with a program manager who’d been displaced from his program because he doesn’t scream or yell at people. (No, I’m not making this up. This is true.) He’s an effective program manager, because he doesn’t tell people to do this or that task. Instead, he tells them the goal and the results he’s
When I teach project management, I teach people to know what success means, and to know what done means (release criteria). One of my students recently emailed me: At work recently, we’ve come upon a scenario where we have no success criteria (or more accurately, success criteria that we can measure in any way).
In my last post, I argued that functional and non-functional requirements are unsuitable for the art of describing requirements. I prefer to discuss attributes of the system instead, and then talk about functionality. (Gause and Weinberg wrote Exploring Requirements, Quality Before Design describe how to do this.) But Laurent, in his Misfits, or there’s
© 2002 Johanna Rothman. This article was originally published on Stickyminds.com, January 2002, as a companion piece to “Release Criteria: Is this Software Done?” Summary: How do you know when software is ready to release? This article discusses one piece of knowing when the software is ready to release–knowing what a successful release would look