Author: Harish Achappa Kallira

CHOW #73- Painting the big picture

Rohit is managing a team that has newly transitioned to agile for the past few months. Over these months, across multiple sprints – the team has been regularly preparing stories for sprints. As part of sprint planning –  they estimate stories using story points and track velocity. The product owner has changes that need to get done and has reached out to Rohit to work with the team and prepare a plan on when they are likely to get done. The team refuses to provide details – as they are agile and will not be able to plan ahead....

Read More

Two reasons to stop sizing during sprints

In many new agile teams, sprint planning is used to discuss the stories, estimate stories in story points and plan for the sprint. However, as many sprints happen – and underlying conversation gets louder. Stakeholders want to know how much will actually get done by the team over few months. Teams are provided with some goals – and asked for a time frame for when most of these would get done. The agile ceremonies –  especially sprint planning and estimation that the team follows do not seem to help. Usually, teams seem to find the high level goals and...

Read More

CHOW #55– How should Swathi handle changing requirements

Swathi has recently started working with an agile team as a product owner. In that capacity, Swathi has end to end ownership of her part of the product, She reports in to a product director. She works closely with the sales teams and operations teams to identify features, proactively suggest changes to reduce operational load. In this release, they are adding several new features for a new client. She has started finding that many times, while internally they are on the same page, feedback from the client has given surprises. This has forced her to make changes, stop some stories and essentially go back to the drawing board – her customer who is first in that market seems to be changing their mind.  The product director has asked her to take a step back, review the whole situation and own the backlog to reduce so much of churn and frustration – given that the client is important and first in the segment. What should Swathi do? How should Swathi approach so that the backlog becomes stable over a period of time quickly.   Suggested Solution: Many times, backlogs are created by understanding requirements, but not the context in which the requirements have been generated. This understanding is critical to manage risks and effective backlog management. In this case, Swathi must consider the volatility and completeness of the requirements in...

Read More

Two techniques to explain your Product Vision

(Rock paintings at Bhimbhetka; dated late stone age, about 30000 years ago. Visual story telling is natural and gets people to quickly gather around an idea and form opinions) In earlier blogs, I had touched upon  how it is important to have clarity on the problem being addressed and the context in which the solution will be used to plan product releases in an agile project. A problem that is well understood leads to a better solution. Applying design thinking techniques help to define a problem well. This blog touches upon a specific techniques used by agile teams to structure and explain the...

Read More

CHOW #38– Creating a right sized product backlog

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...

Read More