Use Case -- Study
Dears,
I need some support and hints to solve this use case:
Thanks
===============================================================
You are in the middle of a small Software development project which is supposed to last for few months and staffed with one development team. The scope was initially estimated at 84 Story Points (SP). The team works in iterations (Sprints), five of which have been completed.
Sprint Velocity(SP)
1 2
2 10
3 18
4 18
5 20
After the second iteration,/Sprint the total scope was reevaluated and increased by 5 SP. After the third iteration/SAprint, the scope increased again by 25 SP.
Questions:
1) What is an approach you would use for reporting on project progression
2) What would you forecast for the project end date
3) Can you assess the project status
4) Assuming that this is for an external client, other than the items above in your experience what are the things that you would think should be tracked and communicated both internally and externally?
1. Hold the Product Owner accountable for value, and how it is being optimized.
2. The end of the current Sprint, unless it is cancelled.
3. Five projects have been completed and a sixth may be underway.
4. Impediments to value delivery and the required sense of urgency to overcome them.
Thank so much Ian,
It is definitely helpful. I have meanwhile prepared an answer. Could you check and comment ?
Answers and comments:
- If there is no scope change, then the project should be completed after Sprint 6 (18 SP) delivery
1) What is an approach you would use for reporting on project progression?
I have assumed two scenarios- But for both below Scenarios:
- Setup Review session with the clients
- Setup Retro-perspective after each Sprint
- Setup Daily Stand Upcall (and invite client from time to time
First Scenario:
The Scrum team delivers the 5 sprints as mentioned and took into consideration both changes (+5 SP in third Sprint & + 25 in the fourth Sprint). The new baseline base is : 84+5+25 = 114 SP
This means we escalate to Resources management/PMO, we order and get additional resources to cope with the first scope change ( +5 SP) before the third Sprint starts + complimentary resources to cope with the second change (+25 SP) before the fourth sprint starts - These additional resources could be released when the fourth iteration is delivered or maintained if we think that we can probably get further scope change. Based on such assumptions, the project will be completed after the delivery of the sixth iteration.
Second Scenario:
The Scrum team delivers the 5 sprints as mentioned and without taking into consideration both changes (+5 SP in third Sprint & + 25 in the fourth Sprint). The new baseline base is: 84+5+25 = 114 SP. The additional scope will be backlogged for the next sprints and based on the team capability/SP
In the second scenario, we can assume two variants (A or B)
- Variant-A: Considering the additional scope(ss), we determine with the customer which USs are the most important for him to be delivered at first. And taking into consideration the resource constraints and the team capability. (No change in SP). That means the 5 Sprints are delivered as Is.
- Variant-B: All scope changes are added on the Backlog and considered for the further sprints, no change on the delivered 5 sprints
2) What would you forecast for the project end date?
- First Scenario:
- Sprint 6 is the last delivery. No delay even after the Scope change but the risk is higher as we have introduced additional scope without modifying the timeline.
- Project duration: If we assume that each Sprint has a duration of 2 Weeks, then the project should be completed in 12 Weeks.
- Second Scenario:
- Sprint 8 should be the last delivery. We recommend Variant-A. On one hand, we respond to customer expectations and consider the prioritization of the US. And in the other hand, we have assessed the risk, and sprints are under control.
- We deliver in each sprint as it is and Starting of the scope change based on priorities.
- 1) Must have
- 2) Should have
- 3) Nice to have
- Project duration: If we assume that each Sprint has a duration of 2 Weeks, then the project should be completed in 16 Weeks.
3) Can you assess the project status?
- The project started with the wrong estimation, or requirement misunderstanding.
- Probable missing coordination between POs
- Grooming sessions and signup US are common activities with customers. All PO (Business Analysis from both sides) should cooperate closely to take correction assumption and consider all priorities. If we get 30 additional SP as scope change. Which is about (33,7%).
- It could mean that, either a sudden customer Requirements consideration due to (new strategy, market orientation, internal change...) or a missing in the requirement from day 1. or misunderstanding from PO on the scope. the scope significance and related requirements.
4) Assuming that this is for an external client, other than the items above in your experience what are the things that you would think should be tracked and communicated both internally and externally? - Why would you pick
Scope change and adaptability are the foundation of the Agile framework, therefore all changes should be discussed and agreed upon before we apply them into the sprints.
I'd observe that you haven't mentioned value even once, and have applied pseudo-Scrum terminology to a project execution model.
I think your approach would greatly appeal to those who would prefer to manage more traditionally by schedule, while paying lip service to certain agile terms of reference. Going by how the questions were framed, I suspect that is likely to be the case in this situation.
What would be your approach?
Any recommendations?
In Scrum, the only purpose of estimation is for Developers to get their arms around how much work they can take on each Sprint. Everything else reduces to empiricism and the incremental delivery of value.
My approach would be to challenge why Sprints are being used in this particular situation, and what outcomes are hoped for.
Thanks, Ian,
The case was provided to me last week in order to be prepared before my interview that will take place next week.
I am open to any further recommendations.
Thanks
It's sometimes the case that an interviewer's understanding of Scrum is not as robust as one might hope. In my experience, a response along the lines you have prepared is likely to be received better than a challenge.
Thank you anyway