What if the requirements are super clear but they change? When do you find out and what happens then? I've personally never had a project where the requirements were 100% clear and stayed exactly the same. Even when writing a v2 of an existing project from the ground up things tended to be unclear and subject to change.
The point is to use what ever works best for your team, not blindly follow some process that may or may not necessarily work for you.
Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.
> What if the requirements are super clear but they change?
You need to communicate with stakeholders then, to change requirements, explain mistakes, set new goals, and reprioritize tasks. Agile (SCRUM/Kanban/etc.) are designed with frequently changing requirements in mind. In SCRUM, this is done at sprint review/sprint planning stage. In Kanban, it's continuous process.
Well then requirements were not 'super clear', they were simply incorrect and it doesn't matter in which way. A very bad start of any project, since beginning you are already putting out flames left and right
viraptor|2 years ago
hu3|2 years ago
midasz|2 years ago
nudgeee|2 years ago
Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.
oneshtein|2 years ago
You need to communicate with stakeholders then, to change requirements, explain mistakes, set new goals, and reprioritize tasks. Agile (SCRUM/Kanban/etc.) are designed with frequently changing requirements in mind. In SCRUM, this is done at sprint review/sprint planning stage. In Kanban, it's continuous process.
saiya-jin|2 years ago