Seven
On Tuesday at ProjectSummit/BA World, I was invited to be moderator of “Agile Analysis: Can it Work at My Organization?” During and after that session I had numerous discussions centered around this recurring question: “What Should I Document, and What Can I Document?” There’s a common perception that on an Agile project, the only thing I’m permitted to write down is a User Story – the remaining communication occurs through verbal interaction. If Agile is all about effective communication, is it presumptuous to assume that verbal communication is the most productive? In 1956, George Miller proposed a theory that the capacity of a human’s short-term memory is seven plus or minus two things. This was proved, and has been proved and re-proved many times. To free up short term memory to make room for the next batch of information, I have four choices: discard it, pass it to someone else and be done with it, encode it in long term memory (this takes time), or write it down. On a project aimed at building anything larger than small and trivial, chances are that if you don’t write things down they will be lost or forgotten. So, the remaining question related to project efficiency is, “If I write information down, what form works best, what do I do with it once it’s written, and what should I do with it after we are done using the information?”
Turn Your Thinking Upside Down - in Boston
For those of you attending "Project Summit" or "Business Analyst World" next week, I hope you'll drop by my presentation titled "Better Software Requirements Through Mapmaking". Expect a few suprises as I turn your perspective on business and software modeling upside down.
I hope to see former friends and colleagues as well as folks from former clients in the area: RSA Security, Applied Biosystems, JP Morgan, Quantum (now Maxtor.) Stop by and let's catch up!
I hope to see former friends and colleagues as well as folks from former clients in the area: RSA Security, Applied Biosystems, JP Morgan, Quantum (now Maxtor.) Stop by and let's catch up!
Great UML Cheat Sheet
A while back I went in search of a great, concise, and up-to-date notation summary for UML and was surprised not to find a decent one, so my colleagues at Improving and I created one. We're happy to share it, and I hope you'll pay it forward by passing it around to others who are learning and/or using UML. The link to the cheat sheet, or as we prefer, "Improving Sheet" is on my sidebar (see the UML logo) or click here. By the way, if you forget who we are, just Google "Improving" and you'll find us at the top of the list. ;-)
Business Requirements vs Technical Requirements
I wanted to blog about the difference between business requirements and technical requirements (because I know you're dying to know.) Instead, I found a clear exlanation/illustration here. You can't go wrong with a whoopie cushion example -fart humor is always a clear winner.
Subscribe to:
Posts (Atom)