Improving Results Through Understanding the Requirements

September 28, 2009

As I mentioned in Those Satisfying Moments, I took up the charge of being a coach for one of our Agile/Scrum teams that was struggling. This team went from being challenged and working overtime to kicking butt, no overtime required! This post covers some simple changes that allowed this to happen.

My first day spent with the team involved a backlog review. The goal was to review the product backlog and re-evaluate the story points that had already been estimated once before by the team. (Story points are relative units of size for those who are not used to the agile vernacular.) Once this was complete we could use the team’s prior velocity determine what the release date could and should be – versus what some of us had in our heads as a release date.

As I sat with the team to review the backlog, Problem #1 immediately surfaced. The Product Owner pulled up a spreadsheet on the large screen that contained the backlog in priority order, with story points assigned. I hadn’t seen this spreadsheet prior to the meeting, but I was the only one in the room who hadn’t.

The team needed to review the items on the spreadsheet, validate or change their story points based on a (presumably) better understanding of what needed to be built because they had been building portions of the system already, and then determine their target end date. It seemed simple enough, until I started looking at the spreadsheet in detail.

I was having a difficult time comprehending what I was looking at. I listened while the team began to discuss the backlog, but part of my brain was occupied with the backlog itself. The team didn’t seem that engaged in the review, either. It only took me a brief amount of time to figure this situation out.

The backlog was a mix of user stories, which are supposed to be simple way of capturing what users want out of the software, and some very specific tasks. And some of those tasks were thoughts about how a one large user story could be handled. Stop right there!

(In fairness, we had experienced a change in Product Owners, so this spreadsheet was a mix of what a prior Product Owner had provided and the new Product Owner what the new Product Owner was still getting up to speed on.)

I made my observation to the team and suggested that we begin with just user stories, leveraging the information contained in the spreadsheet, but clarifying what the users wanted and needed in a way that was understandable to everyone. I got up on the white board and we began crafting user stories with the Product Owner, in front of the entire team.

Some stories were carried over from the spreadsheet. As I mentioned, other stories were tasks, not stories. From my standpoint, I wanted the team to feel committed, to have a sense of ownership. And in order for that to happen, the team needed to understand what we wanted them to accomplish.

As we crafted the user stories, a greater sense of the needs of the customer emerged, in my mind and in the minds of everyone on the team. Two important developments subsequently occurred.

The first involved a user story around reporting needs. Once we took a closer look, there was no real definition provided. Product Owner, that one is yours.

The next one involved working backwards and exploring what some of those tasks in the spreadsheet were designed to achieve. As we discussed the business process and condensed the tasks into a couple of user stories, one developer spoke up and said, “It seems like we’re making the user go through a lot of manual steps.”

This prompted something in the back of another developer’s mind and he said, “How about combining some of these steps and automatically generating the end statement, by-passing the manual, intermediate steps?”

Cha-ching! Now we have a better solution! If we had estimated, built, and tested the solution as presented, we would have missed a significant opportunity for collaboration and a meeting of the minds between the business representatives and the developers to produce an optimal solution. We entered that “ah-ha” zone:

Overall, this planning session helped to tighten up and clarify the requirements, improved the collaboration between the Product Owner and the rest of the team, and provided the customer with a better solution than what had been previously considered.

Everyone involved now had a greater insight on what needed to be achieved, and because of their participation they now had a greater stake in the solution. This alone paid motivation dividends, but there was more.

The conclusion in a couple of days…