It's correct the "warranty period in Scrum?
I'm confused about this question, after passed my PSM1 I'd clear that warranty period is over because you have a DoD that determines the minimum level that your code has to pass and PO validates this uses for the potential deliver.
if a bug is detected in PROD, I think that it's a issue has to be resolved by scrum team in the framework of continuous performing of the product, not thinking in a "warrany period" as waterfall methodology because de DoD ensures that the story is ready and without errors for production.
I would emphatize this section about Scrum Guide:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases
It's correct this?
Thanks
The Scrum Guide says:
The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
Given that a Product Backlog will exist for the lifetime of the product, and that the product will continue to be inspected and adapted, what purpose does the "warranty" you refer to actually serve? What are its terms? How does the "warranty" enhance the ongoing delivery of valuable and "Done" product increments?
Hi Ian,
Thanks for your quickly response. In fact, I want to clarify (or be sure) if the "warranty period" as known in waterfall ( a period that ensure that your long time development doesn't crash in production) has sense in scrum.
You are right in your quote about Scrum Guide, I think that warranty period known in waterfall methodologies is perfectly substituted by DoD, ceremonies that ensure our increment are deliverable and continuous inspecting and adaptating of our product.
Responding "How does the "warranty" enhance the ongoing delivery of valuable and "Done" product increments?" the key is not about ongoing delivery, it's about our product in production. How can our client be ensured that in production in a short-term period this issue still working?, I think that it can be possible if we have a agreed DoD, the ceremonies that ensure that ( inspecting and validate from our PO) and even this a crashcode occurs in pro, we have to create a bug in PB to be fixed as priority PO estimes.
the key is not about ongoing delivery, it's about our product in production
Don't you have ongoing delivery into production, each and every Sprint? If not, why not?
How can our client be ensured that in production in a short-term period this issue still working?
It is not within a team's gift to offer certainty. A competent Scrum Team collaborates with stakeholders so the inherent uncertainty of a complex domain is well managed. As you have indicated, a good team will take care to assure clients that each product increment is Done.
Hi again Ian,
I strongly agree with your way of understanding to what extent the team can commit that the software developed is Done, we must work together to detect errors or changes in development to add greater value to the product.
Thanks for your knowledge.