Document Actions
Agile, Roadmaps, and Requirements: Are they mutually exclusive?
Your developers have gone agile. They want a backlog and user stories. Executives want a roadmap with a longer view. How do you connect strategy with execution? What happens to the roadmap and requirements when you go agile? Attend this session to find out what product managers need to provide to their agile development teams.
Watch Agile, Roadmaps, and Requirements: Are they mutually exclusive?
|
|
About the Presenters
Steve Johnson is a recognized thought-leader on the strategic role of product management and marketing. Broadly published and a frequent keynote speaker, Steve has been a Pragmatic Marketing instructor for more than 10 years and has personally trained thousands of product managers and hundreds of company senior executive teams on strategies for creating products that people want to buy. He teaches several top-rated seminars including Practical Product Management, Requirements That Work, and Pragmatic Roadmapping, as well as many on-site workshops.
Prior to joining Pragmatic Marketing, Steve practiced the discipline of product management for over 18 years at a variety of software and hardware firms and served as head of marketing for the leading provider of performance management software.
Steve writes the Product Marketing blog. Contact Steve at sjohnson@pragmaticmarketing.com
With 21 years of experience in the software industry, and having launched several products following the Pragmatic Marketing Framework, Barbara Nelson is a recognized market-driven product evangelist. As an instructor for more than 7 years, Barbara teaches many of Pragmatic Marketing's top-rated seminars.
Prior to joining Pragmatic Marketing, Barbara served in several product management and marketing positions for Solomon Software (now part of Microsoft). As their vice president of product marketing, she worked closely with product managers, marketers and developers. Barbara helped the company become a more market-driven organization instead of a development-driven organization by applying the principles she learned from Pragmatic Marketing. She attributes her success of building products people want to buy by actively listening to the market.
roadmaps for sales people
Posted by
Steve Johnson
at
2009-06-08 12:19 PM
Sales people often use roadmaps because they don't have a certain feature that's needed to close a deal. They _should_ use roadmaps to show the product's direction, not its deliverables. The problem with committing to certain features in the roadmaps is that you cannot change your plans once you have promised capabilities. A better approach is to start delivering small chunks of work consistently. We can commit only to those items that are sure to be delivered.
I wrote more about this in http://www.pragmaticmarketing.com/publications/magazine/2/2/0312sj
I wrote more about this in http://www.pragmaticmarketing.com/publications/magazine/2/2/0312sj
Reconciliation
Posted by
Rob Magnusson
at
2009-06-05 07:26 PM
How do you reconcile Agile's need for very small work chunks against a roadmap's higher level of abstraction?
execution to startegy
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
It seems that people are trying to find a strategy from within their sprints, while the reverse should be true. So the roadmap should show where you want to go at the high level. Breaking this down into phases of delivery results in your release plan, and then breaking those down to the individual sprints. Development will then estimate the tasks to achieve those sprints.
"prepare the house for sale" is a roadmap theme; "recarpet the game room" is release; and "move all the furniture before the carpet guys arrive" is a development task.
Your team looks to you to set strategy and then rely on them to break it down into manageable chunks.
"prepare the house for sale" is a roadmap theme; "recarpet the game room" is release; and "move all the furniture before the carpet guys arrive" is a development task.
Your team looks to you to set strategy and then rely on them to break it down into manageable chunks.
Question
Posted by
Rob Magnusson
at
2009-06-05 07:26 PM
Do you need to communicate differently with executives/produce different kinds of documents in agile vs waterfall? Specific deliveries vs a prioritized product backlog?
communication with execs
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
The fiction of waterfall was that we could estimate to the feature level exactly what would be delivered on what day. For most companies, releases were a disappointment from either late delivery or fewer features than expected. That's why roadmaps became the artifact of choice for communicating strategy. Execs have more confidence in release themes than laundry lists of features.
Some companies will continue to do extensive market requirements documents but the business plan and product roadmap are the best tools for communicating with management.
Some companies will continue to do extensive market requirements documents but the business plan and product roadmap are the best tools for communicating with management.
Scrum Teams
Posted by
Peter Ghali
at
2009-06-05 07:26 PM
How many scrum teams (of 5-7 developers) should a product owner be able to support?
number of teams
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
One product manager recently told me that he had twelve projects going--he was just running from one meeting to the next and knew that he was being ineffective.
Agile experts tell me that the ideal number of scrum teams per product owner is one. The methods we teach in Living in an Agile World show how to enlighten your teams so that they can use their own judgment. Industry-wide, the average product manager or product owner has three projects. I don't see how you can manage the market research and a prioritized backlog for more.
Agile experts tell me that the ideal number of scrum teams per product owner is one. The methods we teach in Living in an Agile World show how to enlighten your teams so that they can use their own judgment. Industry-wide, the average product manager or product owner has three projects. I don't see how you can manage the market research and a prioritized backlog for more.
Prioritzation Process
Posted by
Alex Burkette
at
2009-06-05 07:26 PM
Can you talk a bit about the prioritzation process and the link between the the priority of the road map item and requiremnt or user story and roles you see leading both respective efforts?
prioritizing
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
We use a method of prioritization that focuses on the market problem, combining the impact of the problem against how many customers (and non-customers) experience it. This way, you look at both urgency and pervasiveness. If you're a product vendor, you want to ensure that the work you're doing is focused on the most important items for the largest number of customers.
So focus on the big roadmap themes and then work on the use scenarios that are related to the theme.
So focus on the big roadmap themes and then work on the use scenarios that are related to the theme.
new vs. enhancing
Posted by
Michael Sturmer
at
2009-06-05 07:26 PM
Is there a difference in roadmap if you are building new vs. enhancing an existing infrastructure.
new vs existing
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
A new roadmap has the luxury of a blank sheet of paper--no existing commitments and no need for infrastructure updates. In a new product, you want to get lots of feedback and you'll find that your roadmap is more fluid, adapting to the customer usage of the product. Once you've got an existing product, the requests become more tactical, more focused. More about evolution rather than revolution.
I use the same format for both new and existing but you need to convey to your execs and your sales team that a new roadmap may change dramatically. You don't want them to make commitments and give you no room to adapt to the changing marketplace.
I use the same format for both new and existing but you need to convey to your execs and your sales team that a new roadmap may change dramatically. You don't want them to make commitments and give you no room to adapt to the changing marketplace.
Requiring a Roadmap
Posted by
Bob Williamson
at
2009-06-05 07:26 PM
What do you do when Marketing requires the roadmap to have release dates on the roadmap when you are in an agile environment? Should roadmaps in agile have dates defined in releases that may be 6 months or further out?
on roadmap dates
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
Sales, marketing, and execs may want more details than are possible to communicate. "What are you having for dinner on June 4th of next year?" Regardless of your development method, I recommend that most companies lock down release dates well in advance. I like a fixed schedule of delivery--once a quarter for most companies--and a variable set of functionality. If that works for you, you assign a theme for the quarterly release and communicate more and more as the capabilities become demonstrable. Even SaaS companies should consider a quarterly cycle to reduce the confusion for their customers. And I've long recommended that waterfall companies deliver less more often. One rule is that your development cycle should be shorter than your sales cycle. (Of course that assumes a multi-month strategic sales cycle, not a short transaction sale).
Question
Posted by
Mark Crosley
at
2009-06-05 07:26 PM
Don't scenarios focus more on the overall context? So user stories more concise, focussed on individual problems?
scenarios and stories
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
Nomenclature is sure tricky in this business. What one person calls a story, another calls a scenario. We've focused on the term 'use scenario' which illustrates a problem for a persona using the language of the persona. So our method in Requirements That Work and Living in an Agile World is "The [persona] has [problem] with [frequency]." Another popular format is typically called a user story which reads, "As a [persona], I want to [achieve a goal]."
Our real aim is to convey market problems to the development team clearly. I suggest a team meeting with some examples of stories or scenarios--and see which format works best for your team. And remember, the problem definition isn't the solution definition, as Barb illustrated with her "8mm by 6mm button" example.
Our real aim is to convey market problems to the development team clearly. I suggest a team meeting with some examples of stories or scenarios--and see which format works best for your team. And remember, the problem definition isn't the solution definition, as Barb illustrated with her "8mm by 6mm button" example.
Agile Stories
Posted by
Mark Crosley
at
2009-06-05 07:26 PM
How are agile user stories different from waterfall scenarios?
stories and scenarios
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
Are they different? Our format is '[Persona] has [problem] with [frequency].' Many waterfall product managers who have attended our Requirements That Work class have found that the way they articulate market problems is unchanged in the move from waterfall to agile. I've found that developers want to understand the problem and embrace this format.
For some companies, those who have been writing "the product shall..." requirements, this approach will be new. Focus on the problem, with the persona as the subject; traditional requirements are focused on the product--and often are feature requests in disguise.
For some companies, those who have been writing "the product shall..." requirements, this approach will be new. Focus on the problem, with the persona as the subject; traditional requirements are focused on the product--and often are feature requests in disguise.
Roadmaps?
Posted by
Tom Lewis
at
2009-06-05 07:26 PM
What are the best practices for creating Product Roadmaps?
best practices
Posted by
Steve Johnson
at
2009-06-09 11:31 AM
The best practices for roadmaps are:
* use an internal roadmap for planning with the team
* use a much less detailed roadmap for communicating to exec, sales, and customers
* focus on themes rather than features
* realize that beauty often makes up for a lack of detail (sales people like 'pretty' ones)
* remember that a roadmap is a plan, not a commitment. The roadmap can and will change over time.
* use an internal roadmap for planning with the team
* use a much less detailed roadmap for communicating to exec, sales, and customers
* focus on themes rather than features
* realize that beauty often makes up for a lack of detail (sales people like 'pretty' ones)
* remember that a roadmap is a plan, not a commitment. The roadmap can and will change over time.
3x5 cards?
Posted by
Guillermo Tellez
at
2009-06-05 07:26 PM
If we are just going agile in 1 month and plan to use VersionOne, would this replace 3x5 cards?
automation
Posted by
Steve Johnson
at
2009-06-08 12:19 PM
In any process, you should understand how the data flows from one artifact to another before you use automation. Do a few dozen index cards to get started, see what data you want to capture (especially market evidence) and once you understand, move them into VersionOne.
Question