PM's responsibility #3: Write and Prioritize User Stories

Once the market and competitors are analyzed, and product requirements defined, it's time for a product manager (PM) to start turning customer feedback, competitive information and the agreed upon product roadmap into appropriate user stories which express clearly and succinctly the development objective. User stories should include the appropriate justification and rationale for the user story including relevant market research and other data. User stories should also include an appropriate release strategy so that the communication with the future users of the new functionality starts even before the first line of code is written.

The user stories are the primary tool for a PM to manage scope, to communicate with engineers, and to verify with other stakeholders that what's being built is really aligned with stakeholders’ needs and requirements. I've often seen user stories written in such way that they make sense to engineers only and with primary intention to organize the work of engineers. That's not a good practice since managing the work of engineers is very different thing than managing scope of the product's functionality being or communicate with non-technical stakeholders. Therefore user stories should be written in such a way that they define the value delivered to the end user and how the functionality will look like from the end user's perspective. The user stories should be broken to as small pieces as possible to still make sense on their own to the end user. My rule of thumb is that every user story should represent a single line in the release notes to the user when the new version of the product becomes available. Such detailed break down enables the PM to efficiently prioritize the most important stories first and let him or her adapt the scope given the success of the engineering efforts. Additionally, it provides a very detailed description what will get built, so that other stakeholders can fully understand if their input was appropriately understood and addressed when product requirements were being defined.

This is part of series of posts on product manager's responsibilities as we see them at Zemanta.