Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff earned a spot as one of the pillars of agile. How do you avoid over-reacting when changing a culture of over-documentation?
Category Archives: Requirements
Provocateurs Gather the Best Requirements
Ask someone what they want, and they’ll tell you they want a faster horse. Provoke them, and they’ll tell you they have a ‘get there faster’ problem, an ‘equine waste disposal’ problem, and issues with total cost of ownership.
Read the rest of the article …
A Prototype is Worth a Thousand Lines of Code
A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.
Posted in Agile, Business Analysis, Business Rules, Interaction design, Interface Design, Product Management, Requirements, Requirements gathering, Software development, UX, Uncategorized
Tagged agile interaction, Communication, process prototyping, prototypes, prototyping, uml as prototype
28 Comments
Use Cases for Iterative Development
Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage requirements for incremental improvement?
Read the rest of the article …
Posted in Agile, Business Analysis, Interaction design, Prioritization, Product Management, ROI, Requirements, Requirements Models, Software development, UX, Usability, Use Cases
Tagged agile development, agile use cases, incremental development, iterative development, satisficing, use cases
17 Comments
Passionate Requirements
Writing passionate requirements is not about writing with passion. It is about writing the requirements that cause people to be passionate about your product. Find the most important problem, for your most important customers. Understand the essence of what is important to solve that problem, for only those people. Then write passionate requirements.
Customer-Centric Market Model
A market can be thought of as the collection of contexts in which you might sell your product. You can split your market into a set of market segments. Each of those segments represents a group of customers, each of whom shares a set of problems for which they would pay for solutions.
Atomic Requirements
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements are important.
Sprint Backlog – Don’t Solve Half of the Problem
Every team that transitions to agile faces this problem – some stories are too big to fit in a single sprint. Most of the teams that I have worked with have the wrong instinct – to solve half of the problem for all users.
The right approach is to first solve all of the problem for a subset of the users.
Verifiable Requirements
Writing Verifiable Requirements should be a rule that does not need to be written. Everyone reading this has seen or created requirements that can not be verified. The primary reason for writing requirements is to communicate to the team what they need to accomplish. If you can’t verify that what the team delivered is acceptable, neither can the team. This may be the most obvious of the rules of writing requirements – but it is ignored every day.
Read the rest of the article …
Foundation Series: Inside A Scrum Sprint
People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me. People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.
Latest Articles
Comments on all Articles
