As I mentioned in a previous blog about how to effectively implement agile, the success of an agile process directly depends on how easy it is to integrate into a daily work routine. I spent some time reviewing my own team’s agile practices looking for ways to make our process even more effective. After analyzing the pain points, I adjusted how we plan and track iterations by removing tasks entirely. Here are some of my observations and how we updated our processes to make them more natural.  

Previously, our team had used a traditional approach to agile where we had features that contained user stories which then contained tasks. We were using features to assign a set of user stories to a given release and we were using the story points on these user stories to get a general idea of how much effort a feature would require. This was an easy approach that prevented us from having to task out each user story individually just to find out an estimated cost for a feature. We would then look at our backlog priority during iteration planning and decide how much work we could assign to each team member. The feature and user stories worked really well. I was able to use burn up charts to visualize our release progress along with any scope creep that had occurred. I plan to have a future blog where I detail some of the charts that we use to track our iteration and release progress.

The problem started with the tasks that belonged to a user story. I was having a hard time getting any value out of the tasks that our team was tracking. At the beginning of an iteration, my team was resistant to creating tasks for each of their user stories and assigning hour based estimates. Partially because it was time consuming, but also because for some tasks they did not have a good idea of how long it might take. We practiced breaking tasks into smaller and smaller pieces hoping it would create more effective estimates. However, time and time again, our estimates were way off. Adding to the frustration, it was very difficult to get my team in the daily habit of updating their completed and remaining hours for each task. Ultimately, we had a burdensome, laborious process that no one was satisfied with – a clear sign that the process needed to change!

I spent a weekend pondering this issue and realized that tracking tasks was providing little benefit while causing a large amount of problems. After reviewing what I absolutely need to report on the team’s progress, I started to realize that I do not need tasks. Listening to my own guidelines about continuous process improvement, I set out to test my theory and remove tasks. I started off small and tested my idea on just one of my teams for an iteration. Instead of creating tasks, we simply looked at past individual story point velocity and used that to determine how many story points to assign to each team member for the upcoming iteration. Once we decided their story point capacity, we looked at the backlog priority and pulled in the items from the top of the list. That was it… The iteration was ready to go, and they did not need to enter any estimates or track any tasks. All they needed to do at the beginning of the iteration was mark whichever user story they were going to work on first as active. Whenever they were done, they could mark it resolved which signaled to testers that it was ready for verification. The tasks were completely removed from our process with no side effect. This made planning an iteration much easier for developers, and it didn’t have any effect on my ability to look at our feature progress. I still have my burnup charts that show how many story points remain in the release and the rate we are closing stories during each iteration. When I want to understand how accurate our story points are, I can look at the timestamp difference between the time a user story was marked active and the time that it was closed. Looking at a scatter plot of story points versus actual time a story was open is another great charting exercise that I’ll explore in a future blog.

After trying this new process for a couple iterations, it is a proven success! The process is now less burdensome and more natural. The real takeaway for this post is even the most mature agile process can use improvements. Take some time over the next few weeks and really analyze what is not working well in your process. Come up with some new ways to solve those problems. Test your ideas on a small group before rolling them out across the entire team. You never know what creative adjustments you might discover. Also, make sure to check back in the next couple weeks as I cover the different types of charts that I use to visualize release progress, iteration progress, and overall story point accuracy.