A common cause for consternation in development projects is when requirements or features are missed in the early stages. Missing requirements in traditional development can be very painful, as the gaps are often discovered either in Quality Assurance or in UAT, or later, which means the majority of the development budget and schedule has already been spent and addressing these new requirements will set the project back a significant amount of time. When using an iterative and incremental method, such as Scrum or Kanban, missed requirements are less problematic because development is usually still ongoing and the requirements can be added to a backlog and re-prioritized. However, this can have adverse effects on the release plan and overall budget, and there is still the risk of learning of the gap too late.

Continue reading →

The topic of writing user stories has come up so frequently that I felt a burning need to write something on the subject.

I’ve seen posts on newsgroups and I’ve received questions from clients about the “correct” writing of user stories. Do we use “Shall” or “Will” or “Must?” Do we start with “As a <type of user>?” or should we start with “In order to <achieve some value>?”

In short, these people want to know how to write user stories effectively, which is a valid question. However, usually with some probing what I uncover is that they’re expecting to use the written user story to communicate the need, which is not a recommended practice. Continue reading →