The reason we write is so that someone can read it in the future. Duh. When we’re writing requirements documents, or documenting processes, how often do we stop and think about who will be reading our documents? We need to make sure our writing will be easy to read for our audience.
Agile / Business Analysis / Process Improvement / Project Management / Requirements gathering
Posted on:
Burndown Bullied Into Business Analysis
Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline – and we can apply it to any form of project-status. In this article, we will apply it to […]
Business Analysis / Requirements / Requirements gathering
Posted on:
Estimating the Effort of Documenting an As-Is Process
Estimating the gathering of requirements is hard. Not as hard as scheduling innovation, but easier than estimating implementation effort. One step in gathering requirements is often the documentation of the “as-is” process – how things exist today. We provide a framework for building those estimates – making the job a little bit easier.
Prioritization / Requirements / Requirements gathering
Posted on:
Vote Early And Often – Getting Value From Brainstorming
Brainstorming can be a simultaneously fun and effective technique for identifying software features or requirements. We’ve written previously about how to facilitate a brainstorming session and how to leverage the results. Timothy Johnson shares another way to use the results effectively. His way is more fun, and maybe just as effective.
Business Process Modeling / Requirements / Requirements gathering
Posted on:
Cost Reduction Potential
All process improvements are not created equal. How should we select which processes (or process steps) to improve? How do we approach this for a really large migration project? Start with understanding the potential for improvement and then narrow it down from there.
Design / Requirements gathering / Usability / UX
Posted on:
Flesh Out Those Wireframes
Stephen Turbek, at Boxes and Arrows, tells us how to get better results from our wireframes. Wireframe prototyping can provide feedback early in the design cycle, reducing costs and improving the quality of the final software. By putting a little flesh on the bone, we can get even better results.
Business Process Modeling / Requirements
Posted on:
Before And After – A Rule For Improving Processes
Nils proposes his rule of three boxes as a consideration when developing software or software features to improve business processes. In short, make sure that you can actually execute the new process. It isn’t enough to create a good “replacement process” – you have to be able to transition to the new process and then back out of it. The new process is plugged into a business ecosystem, and it must coexist with the existing processes.
Agile / Process Improvement / Software development / Software requirements specification / Test Automation / Testing
Posted on:
Insight Into Test Driven Development
James Kovacs shares a great insight on software testing and the software testing process. His epiphany about test driven development makes it obvious to all of us why this technique is so powerful.
Business Process Modeling / Requirements / Requirements gathering
Posted on:
BPMN Diagrams – Make It Right With Intermediate Compensation Events
Sometimes we can’t undo our actions. Water under the bridge. But we can make it right by doing something else to compensate. BPMN allows us to use intermediate events to compensate for mistakes in the past. A classic example is cancellation of a purchase. Our example is a little more fun.