Agile Product Management, Marketing, and More
Posts tagged stories
Prioritizing Requirements
Nov 24th
Posted by John Peltier in Requirements
One of the adjustments an organization must make when moving from waterfall to agile (or, in my organization’s case, partially emulating agile) is the prioritization of requirements. Requirements analysis produces a list of user stories that can be, at least in theory, broken up into chunks to be developed in different iterations. Even if not executing an agile process, this effort by the product management team and/or requirements analysts allows the project manager the freedom to negotiate features in order to meet an organizational deadline.
While asking some stakeholders will only produce a range of “must have” to “really must have,” a more appropriate set of prioritization values is the MoSCoW method:
- Must Have
- Should Have
- Could Have
- Would Be Nice But Probably Won’t
The trick, it seems to me based on a curory explanation of this method, is determining which requirements to categorize at what value: and according to whom. The person providing a requirement is likely to argue for its significance, so perhaps a method of evaluating that allows for quantification of the percentage of the user base affected (or which personas) may be of use.
Stay tuned…
Product Management vs. Project Management
Oct 26th
Posted by John Peltier in Requirements
A frequent topic of confusion among software development organizations is the proper role of a project manager as compared with that of a product manager. Let’s start by defining the terms:
A product manager is responsible for the marketing strategy, direction and features of a product throughout its lifespan. A project manager is responsible for the success and progress of a project on behalf of the project sponsor. The confusion in part can be alleviated by confirming that project != product. A product by definition lives beyond individual versions; whereas in most organizations, a specific version of a product is a project. This is articulated in more detail at How To Be a Good Product Manager:
Project managers are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. As they relate to products, projects can be undertaken to build a product, to add new features to a product, or create new versions or extensions of a product. When the project is complete, the project manager will usually move move to a new project, which may be related to a different product.
Product managers are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle. Other projects related to the product may be initiated, with the product manager being the one constant stream throughout, defining the project goals and guiding the team to accomplish the business objectives that have been defined.
As a product moves through its life cycle, changes are often conceived and added to the project roadmap. The product manager, interested in delivering the very best product to the consumer, is an advocate of adding features that will make the product better or fix oversights regardless of the schedule. The project manager, on the other hand, is interested in specifying an agreed-upon set of requirements and working towards their completion within budget and on schedule. These interests are inherently in conflict.
The answer? In my view, the project manager should be provided a list of stories or requirements for a release (or scrum) that are prioritized by the product manager, so that the project manager has the authority and the knowledge to add and remove stories/requirements as needed in order to come in close to deadline and budget–after all, everything will NOT go as planned, and not all of them will be done on time. What isn’t handled in release 1 is simply held over or deferred for release 2.
In theory, over the course of several releases, as the product is able to meet more and more of the original set of requirements, that product has the chance to succeed in the marketplace.
User Stories
Oct 25th
Posted by John Peltier in Requirements
My team is doing an experiment with user stories; I’m currently gathering requirements for a global licensing module to support multiple applications and regions in my company, and for that project, all goals and customer requirements are being written in the user story format.
User stories are loosely defined as a concise explanation of a need, the person with the need, and the objective that can be achieved by meeting the need. This provides context that a simple “The system shall…” statement cannot. On the other hand, because of the “As a ____, I need ____ so _____” format, user stories are conducive to wordiness. One suggestion to mitigate this risk is to write them initially on index cards–presumably if you’ve filled up the card, you know you’ve written enough or too much.
As for what to write on the card, following the format makes it relatively clear–however, analysis still needs to be applied so that the “I need _____” is completed with the “what,” rather than the “how.” I find it difficult sometimes to step out of the “how,” and sometimes find more “how” than I like to admit when I read old requirements, but the less of it, the better!
An idea that’s new to me is the acceptance story; this is a template that allows the analyst to designate how a requirement shall be deemed satisfied, with the following syntax:
Scenario 1: Title
Given [context]
And [some more context]…
When [event]
Then [outcome]
And [another outcome]…
This may be cumbersome to write for each requirement/story in a requirements document; my first thought, without having tried to implement these, is to write them for selected user stories only–presumably, those that could benefit from additional clarification. Any thoughts?