Jeff Patton has written an interesting post called Requirements considered harmful to spark a discussion on the use of the word “requirements” in the software industry. He argues that the word “requirements” leads us to the wrong behavior. There is a long tradition where we think about requirements as something that has already been decided […]
Requirements – a bad habit Read More »
Traditionally our main documentation issue has often been too much documentation – and being done when we have the least information (at the start of the project). Some agile set-ups have started to have the opposite issue – not enough documentation. There are mainly two different ways this can become a problem: insufficient of long-term
Agile documentation issues Read More »
Most professional project managers are actively handling project risks together with the team. And some of those risks are usually related to the product. But in complex product development I would recommend to have rofuces workshop(s) on product risks – where the focus is on everything that can go wrong in the product. You can
There’s already several articles on splitting of User Stories out there, but I have a slightly different approach – and a new acronym that I like to share so bare with me. My advice is to INVEST in good functional splitting and when functional splitting is not enough you use SOUND advice for additional ideas
Splitting User Stories Read More »
What’s the difference between Agile Requirements and traditional requirements (using some broad generalizations)? A couple of key characteristics sets them apart: Format Purpose Timing Sizing Participation Details Priority Change handling Lifespan Format Agile Requirements can be expressed in any format using any tool. Traditional requirements are seen as text and models in documents (electronic or
Agile vs Traditional Requirements Read More »
