[en] How to create your project map to reach your destination
•
8 likes•3,445 views
Project scope and planning visualization technique based on various product maps. Short Videos (5'-10 ') where this technique is explained in detail: http://www.proyectosagiles.org/videos-cortos-planificacion-agil Version en español: http://www.slideshare.net/xalbaladejo/cas2012-crea-tu-mapa-de-proyecto-para-llegar-a-buen-puerto-v10
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to [en] How to create your project map to reach your destination
Similar to [en] How to create your project map to reach your destination (20)
More from Xavier Albaladejo
More from Xavier Albaladejo (18)
Recently uploaded
Recently uploaded (20)
[en] How to create your project map to reach your destination
- 1. Create your project map to reach your destination October 2012 V 1.3 CAS 2012 Session
- 2. 2 AGILE EXCELLENCE CENTER Government TI - A Technology Xavier Albaladejo is Agile-Lean Coach, IT Governance expert and member of the everis Agile Excellence Center. He helps large organizations in being faster and effective under the principles of Agile and Lean, as well as to train teams in Scrum and Kanban. Xavier Albaladejo is coordinator of La Salle Postgraduate on Agile methods, Certified Scrum Practitioner, founder of proyectosagiles.org, Agile Barcelona and member of Agile Spain Board.
- 3. 3 Index Product Map Inception Design Thinking Empathy maps User Story MappingTechniques for product and users conceptualization, as well as creativity Determine scope Identify key people Stakehol der map Characterize requirements Estimate Identify risks and mitigations Domain Model Solution maps elaboration Architec ture map Planning Prioritization Scheduling The Product Map technique explained in this presentation has been derived from the User Story Mapping technique Product Backlog Activities for creating a project roadmap
- 4. 4 Index 1. What will NOT explain now 1. Inception 2. Empathy Maps 3. Design Thinking 4. User Story Mapping 2. Maps 1. Product Map 2. Architecture map 3. Information map 3. Planning 4. Bonus track 1. Stakeholder mapping 2. Short videos of this technique
- 5. 5 Index 1. What will NOT explain now 1. Inception 2. Empathy Maps 3. Design Thinking 4. User Story Mapping 2. Maps 1. Product Map 2. Architecture map 3. Information map 3. Planning 4. Bonus track 1. Stakeholder mapping 2. Short videos of this technique
- 6. 6 What we will NOT explain right now Inception 1. Why Are We Here? 2. Elevator Pitch 3. Product Box 4. NOT List 5. Meet Your Neighbors - community project 6. Show the Solution 7. What Keeps Us Up at Night 8. Size It Up 9. What's Going to Give 10. What It's Going to Take This presentation will cover aspects related to the green points
- 7. 7 What we will NOT explain right now Empathy Maps http://www.bigvisible.com/2012/06/what-is-an-empathy-map/
- 8. 8 What we will NOT explain right now Design thinking Empathy to the context of the problem, creativity in the generation of knowledge and solutions, rationality to analyze and adapt solutions to the context. Creative thinking in action
- 9. 9 What we will NOT explain right now User Story Mapping Lessrequired/optional time Necessity The backbone The walking skeleton time first release second release third release- + www.agileproductdesign.com / blog / the_new_backlog.html The Product Map technique explained in this presentation has been derived from the User Story Mapping technique
- 10. 10 Index 1. What will NOT explain now 1. Inception 2. Empathy Maps 3. Design Thinking 4. User Story Mapping 2. Maps 1. Product Map 2. Architecture map 3. Information map 3. Planning 4. Bonus track 1. Stakeholder mapping 2. Short videos of this technique
- 11. 11 Maps Discover the puzzle We will develop a product iteratively and incrementally, so that’s why the first step is to discover what are the functional and technical parts of what the product is made and what are the most important ones from the point of view of the customer / user / consumer. This discovery can be done in a workshop in the conceptualization of the project (Inception), in Phase 0 of Scrum. The functional and technical “Maps" or high-level models are elaborated in collaborative way. Modifications to this puzzle (changing priorities, adding new parts, removing others) are done at Product Backlog Refinement (or Grooming) meetings.
- 12. 12 Product map Determine the scope Requir ement To help determine the scope of the product or project, it may be useful to display the requirements in a “frame" that allows visualizing the different parts of the product (or the scope of the project). This allows us to identify the degree of coverage or impact of the project in each area and see what is not covered. Ideally, this "frame" is expressed from the perspective of different users / consumers. For example, functional areas, navigation map of a website, parts of the product, customer services, etc. A two-dimensional spatial distribution can be used to indicate, for example, splitting or refinement of requirements (beyond the basic functionality) in such a way that they can be estimated and prioritized independently, to be developed at different times (incremental development). FUNCTIONAL SUBAREA A1 FUNCTIONAL SUBAREA A2 Requir ement Requir ement º Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Baseline requeriment Specialized requirements Requir ement Requir ement Requir ement Example: FUNCTIONAL AREA A
- 13. 13 Product map Identify key people Requir ement STAKE HOLDER 1 KEY USER Y It is convenient to identify key people in the client organization that should participate in the project to provide the necessary direction, alignment, information prioritization, detail and feedback (stakeholders, end users and technical staff of the client). It may also be of interest to identify key people in the provider organization that will provide support to the project during its implementation. As result, people are associated with specific parts of the product where they have more knowledge or direct participation is required. Requir ement Requir ement º Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Stakeholders and key users who will provide information on prioritization, detail and feedback of the requirements of this functional area Requir ement Requir ement Requir ement Example: FUNCTIONAL AREA A FUNCTIONAL SUBAREA A1 FUNCTIONAL SUBAREA A2
- 14. 14 Product map Characterize the requirements Requir ement FUNCTIONAL AREA A Different colors can be used to classify requirements: Type of functionalities: Capabilities "out-of-the-Box” regarding custom development needs, etc. Functional Behaviors: Basic vs refinement / specialization / alternative paths. This will facilitate the iterative and incremental product development, transversal to various functional areas, with the aim of starting creating a "walking skeleton“ and adding new parts (muscles) to the puzzle, based on their return on investment or risk to solve. User type ("Personas" in the User eXperience technique). Requirements that lacks information or where more research is required. Etc. Requir ement Requir ement º Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Out-of-the-box feature, only requires parameterization. Custom Development needed Immature requirement or where the team must investigate, for example to know its feasibility STAKE HOLDER 1 Requir ement Example: FUNCTIONAL SUBAREA A1 FUNCTIONAL SUBAREA A2 KEY USER Y
- 15. 15 Product map Estimate Requir ement FUNCTIONAL AREA A Requir ement Requir ement º Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Many blue stickers: costly requirement STAKE HOLDER 1 As requirements are identified, the teams asks the Product Owner /stakeholders / end users questions on sizing, in order to make a first and easy quantification of the complexity of each element. In order to do this, you can make a first relative estimate, for example using stickers: the higher the number of stickers, the greater complexity, the greater "size“ of requirement (S, M, L XL). Thus, all participants in the workshop share the same high level vision of what to do in the project, the value provided by each requirement, the functioning of the different parts of the product and the associated complexity: "When you say that in this requirement it has to happen X, are you thinking of "this" and "this"? Or rather "this" is not needed (which would be less expensive)? Example: FUNCTIONAL SUBAREA A1 FUNCTIONAL SUBAREA A2 KEY USER Y
- 16. 16 Product map Identify risks and mitigations Requir ement FUNCTIONAL AREA A Requir ement Requir ement º Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement STAKE HOLDER 1 It is convenient to identify the requirements that have some kind of risk. At this point, the team and the client indicates the objectives / requirements where they believe there may be more difficulty for achieve them (due to dependencies on specific people in the client organization, complexity of the requirements, possible technological difficulties, etc.) and they made a first mitigation approach. Many red stickers: risky requirement Mitigation Mitigation Example: Risk X Risk descript ion FUNCTIONAL SUBAREA A1 FUNCTIONAL SUBAREA A2 KEY USER Y
- 17. 17 Product map Prioritize Quite simply you can make a first prioritization, for example by making the following questions to the Product Owner: 1. What requirements are especially important for your company / department / end users/ consumer, what requirements need to be "touched" before, or what requirements you want to be sure the team understands and to have enough time to adjust them in case of misalignment. Thus, when you are halfway through the project the most important part of the product will be developed, there will be needed only to add less important pieces to an already stable, tested and revised product. 2. What requirements are not so relevant in the project. With these two simple questions automatically appear three requirement sets, within which refine the prioritization (using more complex techniques if necessary). Requir ement FUNCTIONAL AREA A Requir ement Requir ement º Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Requir ement Example: STAKE HOLDER 1 Requi remen t High Priority High Priority Low priority Low priority Low priority Spatially separate post-its into groups based on their high or low priority MitigationRisk X Low priority FUNCTIONAL SUBAREA A1 FUNCTIONAL SUBAREA A2 KEY USER Y
- 18. 18 Product map Global vision Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt FUNCTIONAL AREA A STAKE HOLDER 1 KEY USER AND Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt º Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Mitigation Requireme nt FUNCTIONAL AREA B STAKE HOLDER 1 Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt FUNCTIONAL AREA C STAKE HOLDER 1 Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt º Requireme nt Requireme nt Risk x Risk X Mitigation As a result of the previous steps, at this moment there is a vision of the project scope within a product “frame” that it is not more a "flat" view, given that priorities have been identified transversely to all product areas/sections. This will facilitate to elaborate a iterative and incremental development plan.
- 19. 19 Architecture map Components, risks and no avoidable dependencies In parallel to the elaboration of the functional map (the "what") you can create a technical or architectural map (the “how") indicating also the dependencies and integrations between components, as well as risks associated to some components, systems or integrations. The development order of the technical components of the solution should be aligned with the need to accomplish with the prioritization of objectives / project requirements. However, you should also take into account that the objectives / requirements plan may be conditioned by technical units that are difficult to be decoupled, so these dependencies must be respected in the objectives / requirements plan. Compo nent SYSTEM 1 SUBSYSTEM A SUBSYSTEM B Compo nent Compo nent Compo nent Compo nent 2 SET Compo nent Compo nent Compo nent Compo nent Compo nent Compo nent Mitigation Dependencies or integrations A Risk
- 20. 20 Information map Domain model If you are developing an Information System, in addition to functional and technical maps (and in parallel to its elaboration), it is convenient to diagram, jointly with the client / stakeholders / end users, a simple model (high level) of entities information and their relationships (Domain Model). Note that, like the previous models, this information map can be modified and adjusted each iteration and / or release (e.g. in the detailed requirements workshops and Release Plannings).
- 21. 21 Index 1. What will NOT explain now 1. Inception 2. Empathy Maps 3. Design Thinking 4. User Story Mapping 2. Maps 1. Product Map 2. Architecture map 3. Information map 3. Planning 4. Bonus tracks 1. Stakeholder mapping 2. Short videos of this technique
- 22. 22 Planning Scheduling Sprints and Releases As a first step to develop the Product Backlog and architectural roadmap, requirements and their technical solution may be distributed on a temporal line, through various iterations and releases, using swimlines by to split between functional and technical areas. This also allows: Visualize how from a technology perspective the objectives / requirements will be solved in the project over time, making dependencies explicit if necessary. Establishing a walking skeleton, the Minimum Viable Product (MVP) and the order “Pieces” will be added in different functional and technological areas. Example: Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt FUNCTIONAL AREA A Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt º Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Risk X Mitigation Requireme nt FUNCTIONAL AREA B STAKE HOLDER 1 Requireme nt FUNCTIONAL SUBAREA A1 Requireme nt Requireme nt Requireme nt Requireme nt Requireme nt Requireme ntRequireme nt Requireme nt STAKE HOLDER 1 KEY USER AND Time Risk X Mitigation SYSTEM 1 STAKE HOLDER 1 STAKE HOLDER 1 Product Backlog Architectural Roadmap Walking skeleton Release 1
- 23. 23 Planning Real example FunctionalAreasArchitecturalareas High Priority Risk Mitigation Low priority Costly requirement Swimlane by functional area, team, etc.. Iterations, quarters or releases (in columns)
- 24. 24 Planning Swim lanes and relationships www.enthiosys.com / agile-roadmaps It can be also interesting to consider additional swim lanes to the existing functional and technical views: Type of user or market to be reached Events that occur outside the project but that can impact it Commitments, dependencies with third parties, holidays Infrastructure needs
- 25. 25 Planning Visibility of the rationale of decisions and relationships Threads, or colored ribbons www.enthiosys.com / agile-roadmaps
- 26. 26 Planning Visibility of the rationale of decisions and relationships Colors to identify dependencies between swim lines www.enthiosys.com / agile-roadmaps
- 27. 27 Planning Shared global vision The use of different maps (functional, technical and information) and the systematic use of steps to estimation, prioritization and identification of risks, provide a project overview. The main benefits are derived from making this work in a collaborative way in workshop, facilitating to all participants (including client side stakeholders and supplier team) to maintain conversations, share, align, and get consensus on the initial project vision, scope, priorities, risks / difficulties and mitigations in the beginning of the project, in a very visual and explicitly way. Agile Planning workshop where there are involved customer stakeholders (functional and technical) and the everis development team, supported by its Agile Excellence Center (IT Governance, Technology)
- 28. 28 Planning Progress tracking and change management Using these maps during the project also allows: Make a progress tracking on the global scope (easily understand what remains to be developed). Better visualize the changes and the scope increments (e.g. signaling these situations with colored tags). Assist in change management, by demonstrating the impact of a change on a product scope "frame" (on a functional and technical perspective), which facilitates: Control the “scope creep” and take better decisions, balance the impact of the inclusion of changes in relation to the achieve a reasonable product on time with sufficient consistency and value. Displaying the impact of changes helps to consider their opportunity against the incursion into delays on the date originally planned. Use the concept of "change for free " used in some types of flexible contracts wherein when a new piece of work is introduced into the puzzle, other pieces of an equivalent size are removed. Product Map – Scope follow-up Baseline requirements pending Added or changed requirements Baseline requirements accepted by the customer Requirements dependencies Product Map – Inception
- 29. 29 Index 1. What will NOT explain now 1. Inception 2. Empathy Maps 3. Design Thinking 4. User Story Mapping 2. Maps 1. Product Map 2. Architecture map 3. Information map 3. Planning 4. Bonus tracks 1. Stakeholder mapping 2. Short videos of this technique
- 30. 30 Stakeholder mapping Who is impacted and who could put "sticks in the wheels" Arrows between stakeholders. Colors to differentiate between stakeholder types / areas / departments. Indicate who are in friendship (circles of influence / trust).
- 31. 31 Short videos of this technique Short videos which shows how to planning a project using this technique (in Spanish with English subtitles) . Video Description 1 - Identify the scope of the project (7 ') Agile identification of project scope at a functional and technical level, its complexity and risks in a workshop with the client. 2 - Agile Planning (I) - Ordering (3') Ordering project requirements according to their value, cost and risk in a workshop with the client. 3 - Agile Planning (II) - Product Backlog (4 ') Agile planning in an iterative and incremental way, in a workshop with the client. As a result, a high-level view of iterations and deliveries (Product Backlog) is created.
- 32. 32 Create your project map to reach your destination Questions
- 33. everis.com