A number of my clients are attempting to use agile as they transition from a strict waterfall to a more adaptive approach to their projects. One problem the change artists have is this: The managers, product managers, and maybe even the customers want to define all the requirements up front. I have not found the […]
I received two questions this week about how well does agile allow you to do traceability matrix. Very well is the short answer. Here’s why. If you commit to implementing features (not chunks of architecture) based on user stories in an iteration, you know what you’re planning before the iteration starts. Because you’re working in
I’m an assertive, bold, blunt, and direct person. I try to live within the bureaucracies I encounter, but I don’t always succeed. I’m at SD West this week, where I did a half-day tutorial Monday and am presenting two classes (really talks) today. Before I speak/teach/consult, I like to eat a real breakfast, so
I have an all-in-one machine, a fax/copier/scanner/printer, that I use for copying, scanning and primarily faxing. It’s fine fax machine. And it’s a great copier. But when I hook it up to my computer for scanning to a file, it falls apart. Half the time (or more), my computer can’t establish a USB connection
A colleague asked me what to do when you’re in an iteration and you realize that the story you’re working on spawns other requirements. I suggested that the person add them to the product backlog (the backlog of everything you want to do for the product) and re-rank the requirements in preparation for the next
I’m in the midst of writing the PM book (which is why I haven’t blogged much). One of my tips is that projects have both requirements and goals–and that the PM (at least) needs to know the difference. A requirement can be a use case, user story, a shall statement, whatever. So can a
Don has a great post on Single Point Requirements. You get one example of the requirements: “This product needs to do this. Just this.” Sure enough some months (or years) later, that single example is not sufficiently general to do everything you want the product to do. That’s ok, as long as you plan to
Well, that’s certainly a provocative title. Let’s see if I can back it up 🙂 First, read Keith Ray’s Engineering post, where he says “software development is a cooperative “game” in creating and deploying “knowledge” and various people-oriented practices help make that work” Some of my recent posts about requirements show the problems when software
One of the questions I ask project teams is how they know what to do when. Most of the time, the developers look at me as if I’ve grown two heads and say, “Well, we look at the requirements. We do the high ones first, the medium ones next, and the low ones if we
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