Recent searches
Search options
Administered by:
Anyone has advice on how to deal with "product" demanding a very #waterfall delivery plan (3 months +) from a #Scrum team?
Could you tell us a bit more details?
@scrumschau @engineering_managers
Let's say you have a product that is caught up in focus shifts and feature creep. It grew and grew and grew without really being delivered once. Now you have a massive system, that is not live, but causes numerous scaling (as in we now need to onboard customers with their data) issues because it never had these small feedback loops (or almost none of those at all), right?
1/n
@scrumschau @engineering_managers
Now product wants me to write a delivery plan on how we fix those scaling issues. However, most of them come in like bugs. We plainly cannot anticipate them.
For me, I would go ahead and onboard (that's also what a Principal suggested) the most relevant customers for the stakeholders in batches. Then we see what issues surface. And that's how we move.
However, they want me to provide them with a plan that says: "this will be done on 20th of May."
2/n
@scrumschau @engineering_managers
Which is, of course, very hard for me to do.
My question is, what would you do to find a good compromise?
Thank you! 
3/3
@OddDev @scrumschau @engineering_managers Build in gratuitous error margins to compensate for uncertainty, are write the plans in a generic way ("identify next largest issue", "address Q2-identified issue").
"This will be done in December 2026."
@VincentTunru @scrumschau @engineering_managers That helps a lot. Thank you!