From chaos to managed chaos

There are projects that claim to use some agile method but fail to grow beyond it, instead they just keep on going with the same routine year after year regardless of the outcome. Retrospectives are seen as a time to complain and the actual problems go without attention due to excuses such as lack of time.

I recently worked in a scrum project that started this way with a fixed scope and schedule, requirements in Jira backlog and attitude that all that was missing was the implementation for the features.

In the beginning planning meetings were just like a scene from a weird nerd version of the movie Fight Club, where managers and scrum team fought over how much can be done in a sprint. Meetings took several hours with room full of people resulting in sprints doomed to fail. And fail we did.

Estimation was seen important at that point, so we decided to use story points to reflect the relative sizes of the features compared to each other in order to gain some baseline for team velocity to support the planning meetings. We used a lot of time to think about how we can implement the features so we could have some idea how many story points each feature had.

Even though the stories were extremely technical the approach helped us a lot, and over time the sprints started to succeed. This caused an overdrive in the team and we started to think about more ways to streamline our work. Then we encountered the #NoEstimates movement via twitter: We were intrigued.

We looked at our past couple of sprints and realized that on average our stories had 3 story points, so we did an experiment: we gave each story 3 story points without thinking. This worked like magic, sprints succeeded just as well as before and we did not have to use any time thinking if a story was worth 2 or 8 points.

A few sprints later we revealed our new method to the project stakeholders and suggested that we would move away from story points completely and start tracking the count of stories instead.

Next we focused on the stories themselves: we started to experiment with stories written from user perspective instead of developers perspective; “as a developer I want to write stories from user perspective so I can better understand why I am implementing a feature”. The new stories soon started to bear fruit as we did not need to think each and every technical detail beforehand, customer communication got better and the stories were really fast to write.

Before moving to the new story format, we also switched backlog management from Jira to Wiki. Using Wiki as the backlog gave us much cleaner Jira environment to work with – no unnecessary items were added to Jira. In grooming meetings we would reorder the backlog items and in sprint planning select the top items from backlog to sprint wiki page.

We soon realized that most of our time was spent reordering low priority features and decided to change things a bit. We started to add written goal for a sprint along with a list of high and low priority tasks. Low priority tasks would only be worked on after the high priority tasks were completed. In grooming meetings we would check which of the secondary tasks were not completed and the secondary task list was transferred to the next sprint as high priority tasks, along with new items from backlog as low priority tasks.

The sprint Wiki page had a huge impact on the meetings. Focus got much better as there were no future tasks visible and the grooming meetings shortened from one hour to 15-30min. Now we consider giving up on the planning meeting as it seems just a rubber stamp for the output of grooming sessions.

We have also given up on tracking the story counts for the sprints and the only fail condition for sprint is implementing wrong features. We no longer consider sprint a failure if we encounter something unexpected and cannot implement all the features from first priority list.

I have gained a lot from this experience and I can say from my heart that this has been the only project were I have seen scrum used in a meaningful way. So much so that I feel we can now move past scrum altogether.

I thank you scrum and bid you farewell.