Find story owners

Product managers at Assembla MUST be good story owners. We use this idea to guide our recruiting and training. Every product manager must start with the ability to design and deliver a great feature. An Assembla product manager must understand our product category well enough to be able to be a story owner for half of our features.

But we found that product managers were not enough. We needed to expand our capacity to do story owner work. The solution was to equip a wider range of people to do the work.

Story owners can be professional product owners, but they can also be developers or designers, or come from other roles such as customer service and marketing. Anyone who deeply understands the user and the use case is qualified.

Another exciting possibility is finding "guest story owners" - opinionated users or outside experts who drop in to work with the development team.

We think that newbies can be good story owners if we give them a guide or checklist for doing the work. The Assembla Story Owner Checklist is included below. You can use it as a guide for your own version.

Story owner responsibilities

A story owner should understand the USER of a feature. (It helps a lot if he or she IS a user.)

A story owner must be able to accept a story when it is not completely defined and be responsible for:

• Developing the story so that the goal is clear, adding information to explain it, removing details that are not required, and answering all questions about the story.
• Working with designers and developers to build the feature.
• Improving and finishing the beta version.
• Ensuring that usability is good.
• Releasing the feature to users, communicating with them, and measuring their reactions.

The story owner at work

The story owner has two primary goals for every new feature and significant improvement:

• Get the feature into full release as quickly as possible. It should not become stuck or overly complicated. Accelerated delivery increases the value of our work, because it eliminates partially-finished features that customers cannot use. It makes planning easier, because there are fewer features to track inside the implementation process. It makes development simpler, because developers can focus on a smaller number of tasks at one time.
• Make the feature a great one that people will use, and that users will be happy about. Continue to improve usability right up to the point where the feature is unveiled.

Story owners should work on a limited number of stories, no more than three. They have to finish one of those stories before they can begin work on a new one.

In the Assembla ticket system, a story can be represented by a ticket that is assigned to a story owner. We create subtasks for programming tasks, design tasks and bugs, and those can be assigned to different people. The subtasks go into the same milestone or sprint as the story (usually "Current"). That way, you can manage the backlog at the level of stories, but when you move a story in the current milestone or sprint, you can be assign and track the subtasks individually.

We have two different development paths. "Prototype-driven" stories start with the coding of a prototype version of the feature, which then gets design and usability improvements. "Mockup-driven" stories start with making improvements to a mockup, which then goes to development for implementation.

Developers can release features at any time, without waiting for approval from the story owner. They can use the continuous delivery process at full speed. They use QA and the story owner as consultants. However, new features have switches so that they are only visible to alpha users. The story owner controls the decision about when the new feature is unveiled for all other users.