The team was pumped to start work on the new Inventory SAAS product and eagerly anticipated the first user story writing workshop.  Bert, the product owner, had been doing a lot of up front work to make sure things got off to a strong start. The team was giddy and the room abuzz.

“Okay team, here are first stories that we should cover,” Bert announced as he displayed his list on the large monitor.

• Inventory Quantity Forecast data column display on Item Details page
• Customer Display page using name and address from mainframe CUST_DATA file
• Web service calls to Forecasting system

The developers just looked at each other.

Aaron, one of the more senior developers, asked, “What is the big picture here?  What are we trying to accomplish with this system?”

“Oh, we are going to build a great new product.  I know what we need to do to beat the competition and how all of the pieces fit together so don’t worry about that.  I need for you to get this built as quickly as possible so I have been working hard to be as specific as possible with how the application should work and how it should look,” Bert explained.

Aaron asks, “Can you at least help us understand who the users are?”

Bert shakes his head.  “Don’t worry about that.  I know our users and I defined four security levels with corresponding page and data access rights.”  He displays the security levels on the monitor:

• Guest
• Basic User
• Advanced User
• Administrator

The team could start building the system with these security levels and these types of stories.  Bert could provide the exact details to the team and they could build according to those specifics.  But what would Bert and ultimately his customers be losing in working with his team this way?

A customer walks into a hardware store and asks for a drill.  Does he need a drill, or does he really need a hole in something?

On the surface, Bert is taking away the need for the team to think about what they are creating and whose jobs or lives they might improve. The team will not feel compelled to ask if there is a better way to accomplish Bert’s goals or if the product will be a good fit for the different types of proposed users. The team members will not have a sense of who they are truly working for. What if Bert instead had presented the following list of users/personas:

• Inventory Clerk (high school graduate with basic computer skills)
• Outside Sales Representative (moderate computer skills)
• Branch Accountant (CPA – an advanced user)
• IT Support (site administrator)

Now the team is in a position to better relate to the user base. Aaron asks, “Will the Outside Sales Reps need to access the application via a tablet?”

“Yes, of course.  The user interface needs to support the most popular mobile browsers in addition to the top desktop browsers,” Bert replies.

What about the user stories as originally presented? This product owner is setting the stage for his team to fall into a grind where sprint after sprint they are handed a set of stories to work on without understanding the larger purpose and meaning behind the stories.

What if the “Inventory Quantity Forecast data column display on Item Details page” had instead been written as, “Provide inventory forecast”?  This could set the stage for the product owner and team to brainstorm ways to make this information accessible  throughout the product in ways that could put them ahead of the competition. In the course of this discussion, the developers would gain a sense of purpose and commitment from their involvement in the approach and from realizing the significance of their work.

Creating this sense of purpose is one the product owner’s key motivational tools and cuts to the very core of what makes knowledge workers tick.  Product owners who do this effectively have energized teams that delight them and their customers with every sprint.

Reflections:

• Craft a goal statement for each sprint – not just a list of stories
• Write stories that describe the “what” not the “how”
• Define user roles and personas, not just system security levels