Balancing the variety of work going into the Platform Delivery Team

[tbagnall]

In Alfresco, on our platform we support a large number of code versions, somewhere over 30. The platform is also big, made up of many moving parts. Naturally all of these can produce bugs. 

We also have considerable work on our enhancements, our small increments to the features and architecture of the software.

We bring quite a mix across from these sources into our scrum teams. We have to balance across:

• Items the team discover they need to make improvements on how they work - things that come out of retrospectives
• Feature items - new exciting features or assess, such as the new ReST API we are working on
• Architecture items - to make it easier to support and add features
• Maintenance work - issues that our customer, community and internal users find on previous versions - the 29+ branches we are supporting.

Relatively the first 3 are easy to size. We can use story points based effort using complexity as the most significant indicator, but realising some things are not complex, just hard work.

We wanted to ensure we really were reserving capacity for maintenance and across the three others. We were also faced with a challenge: How do we know we can forecast the number of maintenance items we can get done?

Everyone know it is very hard to size a bug! We are lucky that we have an excellent support part of our organisation, that triage the issues, reproduce them and capture loads of information. Still it is hard to estimate.

As a team we also do not want to include in our velocity fixing issues that we (or previous teams / members) let out the door. It does not seem right.

What we have done for a few sprints is use T-Shirt sizes for these issues. We use labels in our jira tickets. Then as we progress we discover more about the issue. At that stage we resize - in an agile way we re-estimate constantly, and revise our plans. So if we find a ticket is taking 3 plus weeks to get done, and we originally thought it was a T-Shirt size of Extra Small, we revise it to reflect the actual effort we spent.

We have been able to take the T-Shirt sizes and equate them to story points. This allows us to relatively get a ratio of the amount of work we are doing across the 4 sources of work and ensure we are taking care of our support obligation, while continuing to innovate the Open ECM market place with new architecture and features.

At the moment this way works well for us, however we will continue to improve and look to other ways of doing it.

How have you gone about it?