Shamsad is a product owner and is part of a team that has adopted agile. Their team is working on developing APIs for their product which consists of many components. Their team interacts with each of the component interfaces and writes APIs to meet external client needs.
Until now, for every API, Shamsad and the team carefully examine what capability exists in the components and what they need to change before planning a story for the upcoming sprint. They are not aware of the components and this activity provides good learning as well as a review of what they need to do in the sprint. They develop the backlog at least two weeks ahead of every sprint.
The team has been asked to plan scope and set expectations to managment for the upcoming release 4 months away. Essentially, the team has been asked to come up with a release plan. The team tries to explain that the nature of their work does not allow upfront release planning.
They discuss this with their manager – who does not agree and feels even this team can come up with a backlog for the entire release. Anagha, their manager, feels the team is too focussed on the details and suggests that they can do release planning if they manage to create a backlog without all the details of how API must be built. She also tells them to estimate and provide a rough idea of the scope they think will get done.
Shamsad is confused and so is his team; they wonder how can a backlog be developed if it does not bring what needs to be built. Anagha asks them to think through and review their backlog management carefully.
Do you think Anagha has made the correct observations – given the team integrates across many components? Can you help Shamsad and the team develop an approach that will help them complete their release planning and estimations successfully.
Suggested solution:
The manager has made good observations; their API build team along with Shamshad deliberated for a while thinking through the input Anagha gave: to review how they build their backlog.
They decided to try out the following: APIs (interfaces) are primarily used to exchange information in a standard way across systems. So, the primary set of information that comes in is the information that is needed and how that is used.
With this, they went back to Anagha about the details that they plan to use for estimation – just the information needed between systems and how they will be exchanged, rather than details of where they are stored etc. The team was happy to hear they were on the right track.
But, they had a puzzle: How will they estimate the size of the story
Anagha smiled and asked them: what are you estimating, the size of the story (the problem) or the effort required to complete the story. She continued as they still looked puzzled, she asked them to try sizing the story based on the kind of problem they think it is; and not the effort required to solve the problem.
And to help in doing it, she suggested to take a problem they were most comfortable in solving (base story) and categorise rest in to smaller or larger problems compared to the base story.
She also told she will explain about how to arrive at a planning velocity and how based on that, they could arrive at a tentative number of sprints (weeks) required to complete the work; of course, all of this will be based on actual progress.
The team still had a question: when will details be added to the story then; Anagha mentioned that it should be done regularly – before every sprint for stories in that sprint..
The team kind of got it; but looked to her for guiding through this.
