Archive of Lists Articles

Why do we write use cases? For the same reasons that our users use our software - to achieve a goal. In our case, we want to assure that we are creating the right software. By looking at this goal in more detail, we can make decisions that drive the best possible use case creation. Lets apply our product management skills to writing better use cases by writing an MRD for use cases

Pragmatic Marketing has a training seminar called Requirements That Work. In support of that, they provide a list of 8 characteristics of good requirements. We change one and add two more to round it out to The Big Ten Rules. Combine this with Michael’s ten tips for writing MRDs, and we’ve got a good handle on how to create a great MRD.

Michael has posted five (plus five) tips on writing a market requirements document (MRD). Michael has written a good set of tips with detailed explanations and anecdotes. We have re-organized these tips into three general areas of guidance and provide our thoughts.

Martin Fowler has identified the key process elements of making Continuous Integration work. You could even argue that they are the elements that define Continuous Integration (done correctly). We include his list and our thoughts below:

Most guides to writing an executive summary miss the key point: The job of the executive summary is to sell, not to describe.

This from Guy Kawasaki’s recent post, The Art of the Executive Summary. Guy’s article is structured towards pitching an idea to a potential investor. We’re going to apply the same rationale to the communication that is key to successful product development - communication from the team, to stakeholders and sponsors.We also communicate with people outside of our team. We communicate to set expectations with customers, users, and clients.We communicate with sponsors, customers, and others who fund our software development. Without these channels of strategic communication, we won’t have a project, or worse, won’t have a customer when we’re done. External communication is strategic communication.

At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer - nothing.

What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.

This is the second in a three-part post about using tags as a means to organize an automated test suite.

Part 2 of this post can be read as a standalone article. If it were, it would be titled Top five problems with test automation suites. If you’re only reading this post and not parts 1 and 3, pretend that this is the title.

Joy posted a really good article last week at Seilevel’s requirements defined blog, Measuring product manager performance on internal system products. Her post is a followup to an extensive and heated debate that happened last fall on the Austin PMM forum. It’s a great forum to subscribe to - a lot of experienced [...]

The top ten use case mistakes
We’re reiterating the top five use case mistakes from Top five use case blunders and adding five more. For details on the first five, go back to that post.
There’s also a poll at the end of this post - vote for the worst mistake.

Inconsistency.
Incorrectness.
Wrong priorities.
Implementation cues.
Broken traceability.
Unanticipated error [...]

From Start to End has a great post, Some tips on presentations. Very little we can add here - check it out.
Our top five presentation tips (our first four picks are from the list behind the link)

Know your audience. A key preparation - you have to have a goal for a presentation. [...]