Estimating Stories & Vendors Dependence
Hi Everyone.
Recently, i had some very interesting discussions with my team. They are quiet new to estimations & facing some challenges. We came across two interesting scenarios over which i will be glad to have an insight.
- Estimating Business Stories with off-shore vendors who are waterfall
- Estimating Technical Stories
First thing is, they are following scrum but a-lot of their functionality is dependent on partners or offsite vendors. For example my team is Brisbane based and their vendors are Sydney & Melbourne based. Vendor follow a waterfall approach. Sometimes when they plan stories, they can't complete a story in a sprint because their vendors are not able to complete it within 2 weeks cadence. As per the idea, a story is based on INVEST principle and should be giving some business value. Obviously if their functionality is dependent on Vendors, they won't be able to complete that story 'coz of vendor dependence. What they recently started doing was, they started splitting stories as per UI, business layer and data layer. In my opinion, it's not a correct approach. My first advise to them was mock the request and response and complete the functionality. In return they ask, in this way even its not releaseable and production ready. What should be happening in such a scenario?
Second scenario is, how they should be estimating technical stories?
I know, this is not a very new scenario, but some insight will be really helpful.
Thanks,
Beenish
In Scrum, a Development Team are under no obligation to take on work they cannot wholly complete. In your situation, what sort of organizational changes might be needed for all of the requisite skills and resources to be brought within a team, so a release-quality Definition of Done can be observed? Is there an appetite within the organization for those changes and for Scrum to be implemented?
A hybrid scrum approach can be adopted. However, you need to take note that hybrid scrum is a scrum-but. In my opinion, it is fair to apply with good understanding why you are doing so and take actions to shift your development process on Agile track.
What I assume is your team is having integration of technical components with the vendors' product and thus having dependencies to achieve a full end to end release product to customer. In this scenario, you can create stub on those technical components and operating scrum with all the components with full control on hands first. Sprint review can be arranged as a feedback session for all the components you have controlled on hands. This will still help you in terms your collaboration culture build between technical teams and customers.
Thanks.
Since a Development Team must have the skills and ability to deliver an item within a sprint, does it make sense to offer them work that is dependent on outside vendors/teams? You may try to eliminate work being offered to your team unless such external dependencies are not only identified, but also resolved (i.e. - external teams/vendors complete their work prior to the Development Team accepting and forecasting their item(s)).
I know that a Definition of Ready is not discussed in the Scrum Guide, since it promotes the concept of a "toll gate" or checkpoint that is found with waterfall processes, but I have found the above approach beneficial for Scrum Teams that I have served.
On another note, you do not mention your Scrum Team's Product Owner. I would assume your Product Owner can manage such impediments (outside dependencies), and provide sprint offers around work that can be completed according to DoD by the Development Team.
Regarding your estimation questions, the Development Team should only estimate their level of effort/complexity. It is the team's estimate. As estimates are only valid when provided by those who will do the work, it does not make sense to try and account for work performed by outside teams when estimating.
Good luck!