agile > chapter 2 launch and planning > 12 common mistakes

Common Mistakes

It is important that we are aware of common pitfalls when defining and prioritizing requirements.

Pitfalls in writing requirements

We avoid writing the requirements as a description of the system or product. We instead write the requirement from the perspective of the user. "The user can press a button to turn on and off the window wipers" is better than "The car will have window wipers".

By doing this, we focus on delivering value to the customer instead of just adding features that sound fancy on paper but are difficult to use.

Specifications being needlessly detailed

User stories are written in such a way that the user and what they gain from the system or product are the focus. On the back of this user story is the acceptance criteria.

A user story is simple because we want to avoid including unnecessary implementation details (all of the processes and actions it will take to implement the feature) because doing so will waste a lot of time - we may spend more time documenting than we do implementing.

Lacking a definition of "done"

Without a proper definition of done, we will do too much work or too little. Having the conditions under which we will consider a requirement as done will help us to prepare the project Kanban board. As the various conditions are satisfied, the various cards on the board will move from left to right.

The notorious and insufficient categories of "To do", "Doing" and "Done" are the consequence of poorly defining what done means.

Prioritization mistakes

Remember to focus on the business value that will be delivered to the customer. Even if it seems like a feature is of a lesser priority in terms of technical implementation, we should not neglect it because it may very well be a selling point for our product. When prioritizing, we beg the question of "What do we do first" instead of "What do we get rid of".

Splitting requirements

We do not split requirements according to the person that will be assigned to the tasks. Tasks are different from requirements. Tasks are completed whereas requirements are fulfilled. We divide the work associated with a requirement into multiple tasks and distribute these tasks to the team members.

Issues in time estimation

Always include time for unexpected occurrences.