Refining Your Process - Part 2

In my last post I talked about taking a step back and evaluating your software development process to see what's working and what isn't.  I recently did this for my team, and found some places where we needed to improve. The main area of improvement I talked about last time was in the number of stories that were carried over as incomplete from sprint to sprint.   To address this I talked about being clearer about story definitions and acceptance criteria.  

Some other areas of improvement I found were:

• Making sure you realistically account for the number of hours a team member can work on stories.  We had assumed team members were devoting 100% of their time in some cases, because we also track all of our bugs through the Scrum process and thought there would be little unaccounted for time.  This just isn't true -- even an 80% work allocation can be aggressive for some people.  There are certain experts who need to be involved in design and architecture meetings, customer interactions, etc and they will be pulled away from development stories just by the nature of their job.  
• Defining "experimental" stories better -- we have a lot of research stories where we explore new technology.  It is important to define exactly what the outcome of these stories will be -- either a final recommendation, a prototype, or a report on potential uses.
• Dealing with unexpected bug fixes -- if possible, it would be helpful to have a dedicated team who fixes bugs and consults with customers so that the team in the sprint doesn't have to be pulled off to support critical issues.  In practice this is difficult; sometimes experts will be needed to help diagnose issues, especially in smaller companies.  I don't see a clear solution for this, other than leaving team members with slack time, as mentioned in the first bullet point.

I hope this helps to think about your own Scrum and Agile processes and to identify some areas that need attention or improvement.  Learning from your own experience and course correcting as you go is a valuable skill to have that will benefit you and your team in the long run.