How do you prevent analysis paralysis? That’s the question Barbara opens up for discussion on the Business Analyst Blog. The answer is somewhat simple. You stop as soon as you believe you have something that reasonably covers the goals (or use cases) that you are trying to address. When you have requirement completeness, you move on. This answer is both naive and enlightened- especially when you consider the benefits of an agile development process.
Monthly Archives: August 2007
Foundation Series: Heuristic Evaluation
A heuristic evaluation (or heuristic analysis) is a quick, low-cost usability analysis of the design of a user interface. Pareto’s rule tells us that we can get 80% of the results from 20% of the effort. And that’s where discount usability tests like a heuristic evaluation come in to play. Formal, and more detailed usability studies yield better results – but cost more and take more time. A small investment can pay off big with a heuristic evaluation.
A Year Ago This Week on Tyner Blain [2006-08-25]
A look back at the best from a year ago.
Continue reading A Year Ago This Week on Tyner Blain [2006-08-25]
Requirements Details – How Much is Enough?
What is the right level of detail for writing requirements? What about for writing specifications (functional, non-functional requirements, etc)? The answer is that there is no one answer. But there are guidelines, and reasons to write more detail, or less detail – for any given product or project, and any given team. The reason we write requirements is so that they can be read. Understanding the readers is the key to determining which details to include in the requirements.
The Role of the Business Analyst
There’s an article at RQNG with a very interesting discussion thread – do we need the role of a business analyst?
Flashback: A Year Ago This Week on Tyner Blain [2006-08-18]
A look back at the best from a year ago.
Continue reading Flashback: A Year Ago This Week on Tyner Blain [2006-08-18]
Product Managers and Information Flow
Product managers are often described as the hub or center of a software development organization. Saeed Khan takes umbrage with this under-appreciative image in an awesome article about information flow, product managers, and the SDLC.
Why Gantt Charts Are Useless For Agile Projects
What can you learn about your agile project from this Gantt chart? The one above looks out two years. It shows task dependencies and concurrencies. If you’re iteratively developing software, do you really expect to know what you’ll be doing two years from now, to know if you truly have a dependency? You may understand the dependencies with a two-month time horizon. But how much effort are you investing in creating a detailed, two-month Gantt chart? And how much value are you getting from it?
Continue reading Why Gantt Charts Are Useless For Agile Projects
Flashback: A Year Ago This Week on Tyner Blain [2006-08-11]
A look back at the best from a year ago.
Continue reading Flashback: A Year Ago This Week on Tyner Blain [2006-08-11]
Barrier To Agile Development
Why don’t more companies and teams use agile development techniques? We know some teams just aren’t aware of them – although that list is getting shorter every year. The benefits of iterative development over waterfall development are pretty well established. I don’t believe I’ve seen a study that shows that waterfall is more effective. Do people refuse to believe in the data? Or maybe they are unable to believe.