Prakash works as a Product Owner in a software services company which specializes in custom software development for its customer. Prakash has MBA degree in Finance and has good understanding of banking and insurance domains. In his current assignment his customer is an insurance company for whom his team delivers software every two weeks. They have a six people team and typically plan for 60 person days of work in a two week sprint. Last Friday they delivered some newly developed functions to the customer and started a new sprint on Monday. Today, on Wednesday, his customer calls and conveys that he needs two additional fields in the form delivered last week. As customer describes the change required, Prakash understands the importance and value of the change and is convinced that customer would need the change as soon as possible. While the customer urges him to deliver the change quickly, Prakash tells him that he would discuss the change with the team and get back to him. Customer still insists that Prakash should find a way of delivering the change by the end of the current sprint. Prakash does not want to commit anything to the customer without buy in from the team and refrains from making a commitment to the customer. Prakash then calls the Scrum Master of his team and discusses the customer request with him. Scrum Master tells him that the change would require 3-4 days of effort and may not be accommodated in the current sprint. However, as Prakash explains the importance of the change, they decide to discuss the change with the team, explore options and take the decision in consultation with the team decide. What would be your advice to Prakash and his Scrum Master?
- .
- .
- .
- .
- .
Solution to the Chow
If the team is superagile and is able to do multiple releases per day, accommodating such a request from the customer is easy and no discussion is needed. However, the team under consideration here is not that superagile and delivers in two weeks sprints and needs a different consideration.
First and foremost, as scrum team members have a working agreement among them, Product Owners should have customers agree with some working norms and one of the important norms is that any new development or change to the delivered functionality would be taken up after the end of the current sprint. If the sprint length is two weeks, this would mean that customer may have to wait for upto four weeks to see the implementation. Some times this long wait may have negative impact on the customer and there would be pressure from customer to deliver faster. As this is a deviation from the working norm, it may be considered only in an exceptional situation. This should be clear to Prakash and his customer. In any case, no change can be accepted if it is requested towards the end of the sprint. Such a change would go to backlog and may be given the priority it deserves.
If Prakash agrees that request needs to be granted as an exception, he should try to identify if there are any workarounds that he can propose to the customer so that the customer can still get the value he desires while the change gets implemented. That would also enable him not to disturb the current sprint plan. If there are no work arounds, explore what is the minimum that can be delivered so that customer starts getting some benefit with lower impact on the sprint plan.
After Prakash has concluded on taking up the new development, he should discuss it with the team. He would describe the new functionality to the team including scrum master and explain the value or benefits it delivers to the customer and why it needs to be expedited. Further he should be willing to deprioritize some user story from the current plan and include the higher priority item. After Prakash and team communicate the decision to the customer, Prakash needs to have a working session with the customer to re-confirm the working norms and not to have exceptions as much as possible.
