Static Requirements
Hi All,
I have three questions about the use of scrum within an organization where requirements will not change over the course of development due to input from changing market conditions/expectations:
1- does scrum even apply, if so how?
2- is P.O. involvement even necessary after the point at which the requirements are finalized (and development begins)?
3- is there any point in a sprint review on top of a sprint retrospective in this case, if the point of the review is re-ordering the product backlog to account for changing requirements?
Any feedback would be greatly appreciated.
Thank you very much,
Katherine
Hi Katherine,
In my experience, requirements change - all the time!
Even in traditional (waterfall) model, requirements may not change when Architect is authoring documents, but there is a good chance that they change once developers start building the app. Assuming that requirements don't change at all,
- can the fixed set of requirements be divided into logical and individual stories which the team can pick up iteratively?
- what will be the next plan of action if PO identifies that story #123 needs to be taken up before #111? Wait for development to complete and then raise a CR?
- which one sounds better - showcasing what team has built at regular intervals? OR at the end of dev phase only to find that 20% of rework has been identified because of gap in understanding?
I guess, you get the point. :)
Feel free to shoot more queries around this, and always remember - Scrum is not the only framework to be agile.
Cheers!
Adwait.
requirements will not change over the course of development due to input from changing market conditions/expectations:
Have you considered other causes of requirements change, such as a team’s emergent understanding of what those supposedly invariant market conditions and expectations might genuinely be?
When someone argues that if the requirements don't change, I'm not going to question the possibility. Because it's really possible. However, this does not affect the application of Scrum.
We often say that Scrum is designed to solve complex problems. The so-called complex problem is not only from product requirements and market (Problem Domain). It also includes the technology used and the development process itself (Solution Domain).
1. Why do you think Scrum can't be applied to your context? Scrum is a Framework, not a Process or methodology. Within the Scrum Framework, you can design the Scrum process that is right for you based on your context.
2. Writing requirements is not the only work of the product owner. S/He must be responsible for the value of the product. Even if the requirements are clear, the development process may have some trade-offs between cost and value that need to be adjusted.
3. The purpose of Sprint Review is not to re-order the product backlog. Through this activity, the product owner can also review the current development progress and estimate the time to release the product. It is also possible to evaluate the quality and value of the product at this time. The product owner may also make some adjustments to the requirements at this time.
Thank you everybody for your comments, you have more than answered my questions.