Size, Layers and Intuition

As the holidays approach and the cold weather begins moving into Kansas City, it's a good time to reflect on our efforts and goals in the areas of custom software development and agile process coaching.

In the area of User Story Points estimation we made one seemingly subtle change in that we refer to the activity as "Sizing" a User Story rather than "Estimating". For us, it seemed to further focus the discussion on the size of a given User Story, especially when triangulating the story relative to other already-sized stories. This has been useful in a variety of ways, including helping move people past struggling to understand the concept of a story point.

We look at discussing and sizing a story in terms of the elements common to most stories (at least in terms of our software development) which tend to fall in the area of the classic three layers: UI, Business and Data layers. Traditionally, teams have relied mostly on free-form discussion and developer (sizer) intuition to determine point values and during triangulation. While we agree that expert developer opinion and intution is highly valuable, sessions can sometimes be prone to thrashing (excess discussion), fatigue and personality dominance.

When we conduct sizing (using the Planning Poker approach) sessions, we read a User Story card and then the customer answers questions from sizers (developers) until there are no more questions. This is fairly standard in most Planning Poker approaches. But instead of sizers flipping one card to reveal their overall size opinions, they use three cards. One for the UI layer, one for the business layer and one for the data layer. The idea is that since they are already thinking about the complexity and therefore the amount of work involved in implementing a user story and since they usually do this in terms of design,testing and development along the lines of the three classic layers of UI, business and data, we have them assign story layer point values (using the same point scale they would for overall story points) to generate discussion about differing opinions and to confirm assumptions even when their size opinions are similar the first time they flip their cards. In some cases, we'll even have the sizers shout out the objects (Forms, Reports, Classes, Controls, Tables, Stored Procs, Views, etc.) they had in mind across the layers and record those on the wall for a number of reasons, including for reminders of effort we already accounted for in sizing other stories. The resulting layer size opinions and object counts help with triangulation for an overall story size opinion. This is useful for current sizing sessions and for future triangulation as new stories are uncovered during subsequent iterations. The final consideration is developer (sizer) intuition. Even with object counts and layer assumptions in place, if the group feels that similar stories based on the above shouldn't share the same overall point assignment based on their gut that design, acceptance testing, etc. makes the story belong in another point column, then the story gets moved.

Doing the above does add some additional time to the sizing session but it also saves time by reducing thrashing and directing a portion of the discussion along the lines of the story layers. The net result is no more time is taken and a there is typically a higher degree of confidence in story sizes.

Agile Conditioning

Visionpace recently conducted another ScrumMaster Certification course and a few of our associates participated as well students from other organizations. (If you’re not familiar with the course check http://www.visionpace.com/developereducation.html.) The Visionpace folks have been engaged in agile development (XP and Scrum) for anywhere from one to three years as developers. This training allowed them to consider the agile development from the Scrum Master perspective. As such, it generated a lot of good conversation over some recent lunches.

One such topic that I think is universal to all learning, is that one can’t go to a training session and then expect to be fully proficient at the end of the training. Nor can one go to training and not use the skills presented in the training, and expect to retain them. In order to become proficient in a new skill set (be it a new language, new technology, new art form, or new project management approach) one has to continuously use, hone and train with the skill set.

This was the topic of conversation recently. It seems that a lot of people expect that if they send a person to a class and\or have them read a book that they will then be an expert in the topic overnight. (Does this sound familiar? “Jetson, we’ve been hearing a lot about agile development lately and figure if it can work at Chrysler it can work at ACME Sprockets. Attend this three day seminar next week and be ready to tell the Board what we need to do when you get back.”) It’s not unlike your boss telling you to go home over the weekend and read a white paper about swimming and spend a day or two at the pool swimming laps because you’re going to be the captain of the new company swim team. In order to be proficient at anything, you have to train. You have to condition yourself for the skill and continually build on it.

At Visionpace we strongly believe in the phrase ‘Inspect and adapt’ as part of this continual conditioning. Collectively and individually we look at our project and the associated process to see what we’re doing well and what we need to address. We have regular reviews and sessions to help each other get better at being more productive team members.  This is good because it allows us to review and reinforce our actions and processes. Over time we find the results continually improve and as one would expect proficiency increases. A simple concept, that often time is overlooked in organizations.