Will you accept figuring out conflicting requirements as Agile ? .
i understand just in time to gather requirements to have greatest version of it . However my last project , client has documents which are conflicting and we had to spent lot of time figuring what is really true n that’s also when have tight deadline . I heard management saying it’s a Agile world be flexible . I understand n accept if it happens in few instances however we can’t let the burden of conflicting requirement on Agile . Requirements changed due to some valid is totally fine however if customers n their business representative can’t align what they really want how come that burden come to who is implementing the solution .
In other words
Customer changing color of car anytime is ok but one saying red card n other blue car n then let this ambiguity flush through the system is not what should have flown down to development team to work upon . I think it should have worked out upper in the process.
Lets get best of Agile by implementing it in right way at every step .
I heard management saying it’s a Agile world be flexible
Suppose we said: "it's an agile world be empirical". Does that change your view of how evolving and emergent requirements should be handled?
Do you document them is rally or Jira? That way we can show how often requirements are being changed.
if they are changing quite often, it means they are not clear on what they want. In that case get the SMEs involved to get complete clarity on user stories. Get it discussed in retrospective meeting and see if we can improve the process of sprint planning.
@Ekta Gupta, I understand how that must’ve felt being on such a project. However, what was the Product Owner doing? Why was there no immediate conversation with the customer by making the facts transparent, and the impacts it would have on meeting the deadlines?
Ultimately, if the communication between the Scrum Team and the Customer/Client/Sponsor is poor, then Garbage In will result in Garbage Out :)
@Ian Mitchell thanks for your input. I understand and second your thought on Evolving and emergent which is part of rolling wave planning. However when business tells you go get the requirement from x place and consider Y also to validate it . now X and Y are not in consistent and we worked as BA letting them know X and Y need to be in synch to reflect what they want. I can see lot of developers times are being underutilized in such scenarios.
@Steve Matthew thanks for sailing through the journey. PO was also overloaded and exhausted. Issue has been communicated to upper management for lack of proper requirements. However I like to understand whether one should let this kind of mess to handle through agile or they should try to fix their information flow system fixed to get most of the agile .
i understand just in time to gather requirements to have greatest version of it . However my last project , client has documents which are conflicting and we had to spent lot of time figuring what is really true n that’s also when have tight deadline . I heard management saying it’s a Agile world be flexible . I understand n accept if it happens in few instances however we can’t let the burden of conflicting requirement on Agile . Requirements changed due to some valid is totally fine however if customers n their business representative can’t align what they really want how come that burden come to who is implementing the solution .
What do you think where Agile works best and can be useful?
Empirically delivering the solution/increment to an environment where increment can be inspected & adapted accordingly? or delivering the solution based on the set of requirements within the set deadlines with a predicted outcome ?
I heard management saying it’s a Agile world be flexible .
Typically also for customers, isn't it? Expecting that agile is without commitments and the highest flexibility. What they don't understand is that with agile we did not skip Plans. In Agile we still have plans, but the time horizont of our plans are much shorter. Not the whole project, but sprint by sprint. So we cannot react on call, but with the next sprint. If you are the SM, make sure your organization as well as the customer understand this
Nevertheless, if there are conflicting requirements, discuss it with the PO. The PO is the one to transform requirements into PBI and to put those on the PB. For the rest of the Scrum Team the PB is what to do. If other stakeholders of the customer have different requirements, they will need to discuss it with the PO and find a solution or compromise. As the SM, don't let them take over the Review, have them discuss it between them.