Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum challenges – Handling cases where the same team has to work on feature development and also support of previous versions and fixing bugs – Part 1

When we look at a Scrum team, we always think of a backlog of new feature requirement, and how to either develop a new product, or a new version of the product. Thus you will always have new requirements generated by the Product Owner, converted into user stories and the team working to estimate these after breaking them into smaller posts; and doing this new feature would be exciting and challenging for them. However, when you consider the case where you are developing a new version of the product, life is not so simple. Even though the scrum team is focused on new feature development, the existing releases need to be supported. Even when there is a customer support call center, the product team does need to do a lot to support existing customers (and you can be sure that getting team members to do any kind of support activity is not very enthusing for them – however, it needs to be done). For a company, it is very important that existing customers get the required level of support, such that they are not turned off. This support can be in the form of consultation, can be in the form of working with customers (including remote working with their machines) to diagnose problems that they are facing, and also to release bug fixes and patches to customers on a regular basis. And there are no others teams to do this, a lot of these activities would need to be done by the core product team. But, and this is the big question, if you get team members involved in such kind of production support, it takes away effort that they could have otherwise spent for their new feature work, and hence the overall work done in the Sprint cycle gets refused. When there are teams that do not account for the loss of work caused by these kind of production support activities, they will usually find that for some reasons, they are not able to do everything that they initially planned for at the beginning of the cycle, and in many cases, it is not easy for them to detect as to why this is happening.
So what is it that can be done ? Well, this is a several step answer.
The first step is that the company / Scrum team must step back from any commitment to spending this much effort on production support, and evaluate the priorities for the group. This does not mean that the team does not do any production support, it means that the team stakeholders, with a major focus on the Product Owner, work through the expected amount of production support for every Sprint cycle, and balance these against the work being done for the new feature work. In some cases, this prioritization could mean that the team decides that the cost of not spending a lot of time on production support is lower than the cost of taking time away from the new feature work (or on a realistic note, it is actually determined that the cost of postponing the more intense production support is balanced off against the impact on new feature work). When such schedule prioritization comes into play, it becomes a bit easier for the Product Owner since he / she is able to various comparisons:
– Do the required amount of production support and reduce the current feature work
– Do a bare minimum production support with minimal impact to current feature work
– Postpone the major effort involving production support for future months (even though there will be some cost involved)

In the next post, I will explain more on this topic ..

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>