Search

Deliver High Business Value With Agile Opportunity Canvas

I would like to start this blog with a question. Business case, quite commonly used term in Project Management. Do we agree?It is a document explaining the justification for a project and expected outcome. Let us have a look at Project, Program and Portfolio Management in the image below.Every single initiative or project within an Organization is aligned to Organizational strategy.In an Enterprise level, we tend to see a lot of ideas and requests emerging from stakeholders, clients, internal teams, outcomes of market research. These ideas and requests will convert into a Project, if we see a potential opportunity. In traditional approach or Agile approach, every idea or request should be validated to ensure the right investment is made. Agile is a widely used terminology in IT industry. People often stumble upon understanding Agile and Lean. Lean Methodologies focuses more on value, elimination of waste and delivering the product in small batches. Agile is a subset of Lean thinking. Agile movement was formed in 2001, Outcome of which is Agile Manifesto and 12 Principles for Agile Software development. Agile is an umbrella term covering different methods and frameworks such as Scrum, Scrumban, XP, FDD etc. All Agile approaches/frameworks emphasizes more on Agile Manifesto and 12 Principles.Agile Model:Demand Management in Traditional Approach/Waterfall model: In the traditional approach, a project is selected over another project through Project evaluation tools such as Cost-Benefit analysis, Decision Matrix etc. A project charter will be created during the initiation phase of the project which captures business case, high-level requirements, timeline/milestone, risks, costs and other constraints. A detailed scope in the form of "Statement of Work" is approved during the planning phase. Planning is one time in a Waterfall model and will take a considerable amount of time in the project. Scope(Feature) is Fixed, Time and Cost is flexible in Traditional approach. Any changes to the scope will be difficult to handle in Waterfall model. There are a lot of risks involved in Traditional approach, as planning is one time.                                                                                                       Fig: Iron triangle- Traditional Approach Demand Management in Agile Approach: In the Agile approach, planning is continuous. Planning is done at different stages. This reduces risks.Strategic PlanningPortfolio PlanningProduct PlanningRelease Planning – Quarterly by entire teamIteration Planning – Bi-Weekly by entire teamDaily Planning – Daily by entire teamFrequency and required participants for Strategic, Portfolio and Product planning will differ across organizations.                                                                                                         Fig: Agile Estimating and Planning In the Agile approach, Feature remains flexible, Time and cost are fixed. Agile approach is incremental and iterative in nature. In the Agile approach, we do not have a detailed scope slated during the start of the project. As we evolve during the development phase, there might be new features or enhancements identified by the customers.                                                                                                          Fig: Iron triangle- Agile Approach In Agile Demand Management Cycle, an idea/requirement/enhancement is chartered in an Opportunity Canvas which gets reviewed by Investment cabinet. As per agile manifesto # 3- Customer collaboration over contract negotiation and Agile Principle # 1: Satisfying the customer is of highest priority: "Agile opportunity canvas" creates more visibility to the customer and the product owner to prioritize new requirements or enhancements over others. (Enhancements which needs a development effort of minimum 2 months would be considered to be chartered in an Agile opportunity canvas). Demand Management process is followed in both Traditional and Agile approaches. In Traditional approach, since the scope is clear it will be a one-time activity. But in Agile, as we do Rolling wave planning on shorter time span to deliver customer value, we would need a robust demand management process to ensure the right requirements were approved and investment is made for right product or feature.                                                                                              Fig: Opportunity Canvas & Demand Management Agile Opportunity Canvas: Agile Opportunity Canvas also referred to as Agile Project Charter is used to ensure whether the business value is captured in the right format, which gives visibility to higher management and decision makers to ensure the investment is made to the right effort. An opportunity canvas is similar to a lean business case. It will help us capture the essential fields. Drafted opportunity canvas will move through the approval process before any project work is initiated. Sample Agile Project Charter template:There are different elements in an Agile Project Charter. These elements are customized according to the Organizational needs.  Opportunity Canvas is a living document and it should be in One page.In a nutshell, we should have the required elements populated to move it across the Demand Management. Generic elements to be part of the Opportunity canvas are listed below:Current Problem Statement – Why do we need to implement this idea? What is the Problem statement?Strategy/Value Justification – What is the value proposition this idea provides and what strategy are we adopting.Scope – In scope and Out of scope details for the generated idea/ enhancement.Sponsors and Stakeholders – This could be internal or external to the organization.Financials – What are the costs and benefits associated?Success Metrics – SMART Metrics towards the investment. (Specific, Measurable, Achievable, Realistic, Time related)Resources -  Who are the resources going to be engaged? What are the procurement needs? What are the infrastructure needs? Etc.,Agile Project Charter Benefits:Agile Opportunity Canvas creates transparency across the entire organization.Provides a rational route and logic of purpose to the entire team from the beginning to the end.Product Portfolio is maintained and prioritized effectively.It helps avoiding duplicate efforts.It also helps in identifying, if the idea/project/ feature is the latest trend in the market.Agile opportunity canvas can be updated during the planning phase and execution phase. During evaluation or closure phase, the project or solution is validated against the success metrics scripted in Opportunity canvas. Success Metrics in Opportunity canvas does not need to be Objective (directly related to Monetary benefits) all the time, it can be subjective (related to value achieved) as well, depending on the nature of the solution and project.
Rated 4.5/5 based on 1 customer reviews

Deliver High Business Value With Agile Opportunity Canvas

428
Deliver High Business Value With Agile Opportunity Canvas

I would like to start this blog with a question.
 
Business case, quite commonly used term in Project Management. Do we agree?
It is a document explaining the justification for a project and expected outcome.
 
Let us have a look at Project, Program and Portfolio Management in the image below.
Oraganization strategyEvery single initiative or project within an Organization is aligned to Organizational strategy.

In an Enterprise level, we tend to see a lot of ideas and requests emerging from stakeholders, clients, internal teams, outcomes of market research. These ideas and requests will convert into a Project, if we see a potential opportunity. In traditional approach or Agile approach, every idea or request should be validated to ensure the right investment is made.
 
Agile is a widely used terminology in IT industry. People often stumble upon understanding Agile and Lean. Lean Methodologies focuses more on value, elimination of waste and delivering the product in small batches. Agile is a subset of Lean thinking.
 
Agile movement was formed in 2001, Outcome of which is Agile Manifesto and 12 Principles for Agile Software development. Agile is an umbrella term covering different methods and frameworks such as Scrum, Scrumban, XP, FDD etc. All Agile approaches/frameworks emphasizes more on Agile Manifesto and 12 Principles.

Agile Model:
Agile Model:Demand Management in Traditional Approach/Waterfall model:

In the traditional approach, a project is selected over another project through Project evaluation tools such as Cost-Benefit analysis, Decision Matrix etc. A project charter will be created during the initiation phase of the project which captures business case, high-level requirements, timeline/milestone, risks, costs and other constraints. A detailed scope in the form of "Statement of Work" is approved during the planning phase.
 
Planning is one time in a Waterfall model and will take a considerable amount of time in the project. Scope(Feature) is Fixed, Time and Cost is flexible in Traditional approach. Any changes to the scope will be difficult to handle in Waterfall model. There are a lot of risks involved in Traditional approach, as planning is one time.
 Iron triangle- Traditional Approach                                                                                                        Fig: Iron triangle- Traditional Approach 
Demand Management in Agile Approach:
 
In the Agile approach, planning is continuous. Planning is done at different stages. This reduces risks.

  • Strategic Planning
  • Portfolio Planning
  • Product Planning
  • Release Planning – Quarterly by entire team
  • Iteration Planning – Bi-Weekly by entire team
  • Daily Planning – Daily by entire team

Frequency and required participants for Strategic, Portfolio and Product planning will differ across organizations.
Agile Estimating and Planning                                                                                                          Fig: Agile Estimating and Planning 

In the Agile approach, Feature remains flexible, Time and cost are fixed. Agile approach is incremental and iterative in nature. In the Agile approach, we do not have a detailed scope slated during the start of the project. As we evolve during the development phase, there might be new features or enhancements identified by the customers.
Iron triangle- Agile Approach                                                                                                           Fig: Iron triangle- Agile Approach

In Agile Demand Management Cycle, an idea/requirement/enhancement is chartered in an Opportunity Canvas which gets reviewed by Investment cabinet.
 
As per agile manifesto # 3- Customer collaboration over contract negotiation and Agile Principle # 1: Satisfying the customer is of highest priority:
 
"Agile opportunity canvas" creates more visibility to the customer and the product owner to prioritize new requirements or enhancements over others. (Enhancements which needs a development effort of minimum 2 months would be considered to be chartered in an Agile opportunity canvas).
 
Demand Management process is followed in both Traditional and Agile approaches. In Traditional approach, since the scope is clear it will be a one-time activity. But in Agile, as we do Rolling wave planning on shorter time span to deliver customer value, we would need a robust demand management process to ensure the right requirements were approved and investment is made for right product or feature.
Opportunity Canvas & Demand Management                                                                                               Fig: Opportunity Canvas & Demand Management

Agile Opportunity Canvas:
 
Agile Opportunity Canvas also referred to as Agile Project Charter is used to ensure whether the business value is captured in the right format, which gives visibility to higher management and decision makers to ensure the investment is made to the right effort.
 
An opportunity canvas is similar to a lean business case. It will help us capture the essential fields.
 
Drafted opportunity canvas will move through the approval process before any project work is initiated.
 
Sample Agile Project Charter template:
Sample Agile Project Charter templateThere are different elements in an Agile Project Charter. These elements are customized according to the Organizational needs.  Opportunity Canvas is a living document and it should be in One page.

In a nutshell, we should have the required elements populated to move it across the Demand Management. Generic elements to be part of the Opportunity canvas are listed below:

  • Current Problem Statement – Why do we need to implement this idea? What is the Problem statement?
  • Strategy/Value Justification – What is the value proposition this idea provides and what strategy are we adopting.
  • Scope – In scope and Out of scope details for the generated idea/ enhancement.
  • Sponsors and Stakeholders – This could be internal or external to the organization.
  • Financials – What are the costs and benefits associated?
  • Success Metrics – SMART Metrics towards the investment. (Specific, Measurable, Achievable, Realistic, Time related)
  • Resources -  Who are the resources going to be engaged? What are the procurement needs? What are the infrastructure needs? Etc.,

Agile Project Charter Benefits:

  • Agile Opportunity Canvas creates transparency across the entire organization.
  • Provides a rational route and logic of purpose to the entire team from the beginning to the end.
  • Product Portfolio is maintained and prioritized effectively.
  • It helps avoiding duplicate efforts.
  • It also helps in identifying, if the idea/project/ feature is the latest trend in the market.

Agile opportunity canvas can be updated during the planning phase and execution phase. During evaluation or closure phase, the project or solution is validated against the success metrics scripted in Opportunity canvas. Success Metrics in Opportunity canvas does not need to be Objective (directly related to Monetary benefits) all the time, it can be subjective (related to value achieved) as well, depending on the nature of the solution and project.

sayee

sayee krishna

Blog Author

Join the Discussion

Your email address will not be published. Required fields are marked *

Suggested Blogs

Agile Project Management Vs. Traditional Project Management

In this fast-moving world, project management has become one of the most important pillars that are helping businesses run without any glitch in their processes. Both small and large scale organizations around the world are exploiting technology and depending on project management systems to deliver the software development project successfully. Whether it is team workflow management or timing, these tools help to ensure that everything is going well without any obstacles. While there are tens of different project management approaches, Agile is considered one of the most practical and flexible software development mechanism that exist today. It is capable of executing a variety of tasks, but what sets it apart from others? Let’s find it out. Here’s a brief comparison of Agile management and traditional project management software:                                                                                                                    Traditional vs Agile Project Management Overview of Agile and Traditional Project Management What is Traditional Project Management? The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in sequence. Its concept depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure above. The entire project is planned upfront without any scope for changing requirements. This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues. What is Agile Project Management? When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility. It is an iterative approach that focuses more on incorporating customer feedback and continuous releases with every iteration of software development project. The basic concept behind Agile software development is that it delves into evolving changes and collaborative effort to bring out results rather than a predefined process. Adaptive planning is perhaps the biggest feature of Agile and one that makes it a crowd favorite among project managers. Scrum and Kanban are two of the most widely used Agile frameworks. They are very well known for encouraging decision-making and preventing time consumption on variables that are bound to change. It stresses customer satisfaction and uses available teams to fast-track software development at every stage. The table below shows the major differences between Agile project management and traditional project management.                                                                                Table: Agile project management vs traditional project management Why is Agile Preferred and why not the traditional project management? Agile is preferred by most developers and managers because of a variety of reasons. Let’s have a look at the most common ones: Project complexity Traditional: This method is the best fit for small or less complex projects as it follows linear approach. Sudden changes in the project or any other complexities can block the entire process and make the team go back to step one and start all over again. Agile: This is the best methodology to follow in case of complex projects. A complex project may have various interconnected phases and each stage may be dependent on many others rather than a single one as in simple projects. So, Agile methods are preferred for large complex projects, as they can respond better to such structures. Adaptability Traditional: This approach works with a belief that once a phase is done, it will not be reviewed again. So, it is not adaptable to rapid changes in the work plan. In case if any sudden situation arises or any change in the requirements from the client’s side, traditional approach fails to adapt to the new change. The only choice is to start from the very beginning once again. This wastes a lot of effort and time in the process. Agile: The adaptability factor is very high in this methodology since it is not linear. Complex projects consist of several interconnected stages, where a change in one stage can cause an effect on another. And the project managers can take calculated risks in such scenario, as there is a chance of high adaptability.  Scope for feedback and changes Traditional Each and every process is clearly detailed and defined at the start of the project in the traditional approach. It cannot deal with any big change or feedback that might require a change in the process. Mostly, the project delivery time and budget are fixed, allows change very rarely. Agile There is a high acceptance for feedback and change in this method. The process is very flexible and allows constant feedback that can help to provide better output within the fixed project delivery time. The main reason that managers or developers choose agile direction is for the flexibility it offers. Developers working with Agile management are able to respond to customer requests quickly as they are only addressing small parts of the project at a time and the customer validates each iteration or sprint before finalizing.   Some of the important characteristics of Agile development Breaks project into parts Agile divides a project into parts (called iterations) where the release is sent to the customer after every single iteration. Additionally, the success of the project can be easily foreseen through the success of these iterations. This removes the need for upfront planning completely. Self-organized As mentioned above, Agile uses a parallel mode of management. Employees of a company are not managed by a central line of control, but by groups. For example, in Agile, there may be eight teams working on a single project. Each team is managed by itself without external guidance. The teams only interact with each other for project discussion and process linking as they are otherwise not self-sufficient. Generally speaking, an Agile project consists of three parts: The product owner – the expert on the project (for which the product is being developed) and is the main person who oversees the projects The scrum master – this person manages the process involved in Agile. He/she looks after the iterations and its completion The team – individuals who play significant and minor roles in the software development process Customer Engagement In Agile, customer engagement is at the very top. The customer is regarded highly in its frameworks as after every iteration, feedback is generated and acted upon. Overall, Agile is clearly the winner among project management systems. When compared with other traditional approaches, Agile’s features come to the fore and reiterate why it is one of the top software used by companies globally. Can Agile Coexist with Other Approaches? This is a question asked by many project managers, and opinions of experts seem to be divided. While some say it is possible for Agile to coexist with traditional project management systems, they suggest being cautious and using them for different terms. For example, using two different approaches on the same project can be counter-productive and highly explosive. As Agile and most other frameworks are totally contrasting to each other, the projects may go for a toss. On the other hand, some experts believe that it is not possible for Agile and other tools to co-exist because of their contrast. Using them together can cause disorder in the entire company system, making the productivity to go for a toss. Agile vs Traditional- Adoption Growth According to a recent online survey of 601 IT and development professionals, it is proved that Agile is the new typical formula for project success. The majority of projects and development teams are now adopting this methodology, while the traditional waterfall approaches have many flaws.    Traditional organizations vs. #Agile organizations #SALC16 pic.twitter.com/bBgxkQB1fI — Scrum Alliance (@ScrumAlliance) January 20, 2016 Agile was first introduced about 15 years ago as a substitute for traditional software development approaches. Many people considered it as challenging to implement traditional approach practices and Agile adopters stated that this new style of software development improves team collaboration and is more customer-centric.  Though Agile method was present more than a decade ago, the vast majority of organizations have adopted the practice in the last 5 years. Moreover, the survey reported that agile adoption saw an inflection point between the year 2009-2010. As shown in the above figure, agile adoption seems to have slow incremental growth till 2008 and then its growth was accelerated after gaining traction in the market. Reasons for the transition to Agile Most of the organizations who transitioned from traditional to agile project management have listed the following reasons: Improves collaboration between teams- 54% Enhances the quality level of software in organizations- 52% Results in enhanced customer satisfaction- 49% Speeds time to market- 43% Reduces development cost- 42% The Verdict In the traditional software development, the customer involves only before the start of the development process. So, there might be a number of mistakes and a large amount of money needs to be spent to rework on them. Since in the Agile software development, the customer involves at each stage, the corrections can be made once the defects are detected. This helps us in saving cost. As we can see, Agile project management is really in-demand for teams. It helps the team to work on the top priority ones at the right time and allows them to walk through the risks much faster than they would with traditional project management tools.
Rated 4.0/5 based on 5 customer reviews
8746
Agile Project Management Vs. Traditional Project M...

In this fast-moving world, project management has ... Read More

5 Scrum Boards that perfectly depict project progress

Quite possibly, few tools are as simple – yet as powerful – as a Scrum task board. Teams that plan their work in sprints use these boards during each sprint to visually depict where they are at. Just by looking at the task board, it is possible to evaluate the progress and judge whether the sprint is on track or not. In its simplest form, a task board has a list of tasks that are categorized as yet-to-start, ongoing and completed. Over the years, Agile teams across the world have created their own adaptations of the traditional Scrum board….have a look, and decide which one will work for you! The Scrum wall                                    Photo credit: http://jalbum.net/blog/entry/getting-ready-to-launch-the-new-site Teams that use up the entire wall as a Scrum task board get extra space that can be put to good use. They can put down all their information in one place, with additional inputs like the overall calendar, backlog, decisions, comments and so on up there for everyone to see. Say it with Lego!                                                             Source: http://agilethings.nl/creative-planning/ We always knew Lego was versatile, but this gives the concept of versatility a whole new look! This team uses a Lego planning board, with rows depicting user stories and columns depicting weeks or sprints. Each team member is assigned one colour, and the numbers of bricks in that colour show the exact time availability of that member. A long 4 stud brick indicates a full day of work, while a two stud represents a half day. A fun and creative way to plan your sprints! Hourglass Scrum/Kanban board                                 Source: http://www.strongandagile.co.uk/index.php/the-hourglass-scrumban-board/ An hourglass is a fun way to depict the flow of tasks. Work in progress tasks are the ones at the neck of the hourglass; completed tasks are moved below and the pending ones are in the top half of the hourglass. Note that when the WIP tasks are limited to one in each story( as the space in the neck is narrow), they get more attention. Release Radar                                              Source: http://agileboardhacks.com/tag/portfolio-management/ By turning the traditional board into a circle, this team led by Daniel Aragao of Thoughtworks created a great way to deal with prioritising urgent tasks. Items in the outer rings of the circle are not urgently required, while those closer to the centre are needed asap. Each slice of the circle represents a project , which is identified by a sticky note on the outer edge. Scrum for Trello Teams that work in different locations and across various time zones need a virtual Scrum board to track work progress. Trello is often used to manage task boards and sprints, with a Firefox/Chrome extension called Scrum for Trello. Innovation is the key to success. What works for another Scrum team may not work as well for you; try out your own tweaks and quirks, and customise your own Scrum task Board. You can learn more about Scrum tools and techniques by attending a CSM Training from a certified trainer. Happy Scrumming!
Rated 4.0/5 based on 20 customer reviews
5 Scrum Boards that perfectly depict project progr...

Quite possibly, few tools are as simple – yet as... Read More

5 Reasons To Have Fixed-Length Sprints

Should the sprint length in Scrum be fixed or variable? It has been a hot topic of discussion for years but most of the experiences shared by Scrum Masters go in favour of fixed length sprints; and, I too follow the rule of fixed length sprints. According to Agile Cadences and Technical Debt Survey report, 68% Scrum Masters favoured fixed length sprints while 29% accepted to make infrequent changes in the sprint length. Only 7% Scrum Masters accepted to change sprint length frequently as and when required. No doubt, flexible sprint length releases work pressure on the members but this practice develops a number of undesired apparent or hidden snags pertaining to quality, cost, time and scope.  Here in this article, I will explore 5 more commonly accepted reasons to adopt fixed-length sprints framework.  1. Teams Benefits from a Regular Rhythm Regular time-boxed delivery is the core Scrum discipline; therefore, we can’t take the liberty to have flexible sprint lengths. In case of flexible sprint lengths, team members are unsure of schedule. The fixed duration sprint benefits the Scrum teams because each member has to be settled with a rhythm.   2. Sprint Planning Becomes Easier The fixed sprint length makes the sprint planning easier because the team members know how much work they are supposed to deliver in the forthcoming sprint.  3. Tracking Velocity Is Easier Tracking Scrum velocity is easier with same length sprints. You can’t be sure of completing twice the amount of work if the one-week sprint period is extended up to two weeks. The alternative practice may be to normalize the velocity on per-week basis, but it seems a needless and complex exercise if the Scrum sprints are kept at the same length.   4. On the Time Course Corrections It is very common to find a gap between the demand of the product manager and the amount of work delivered. Fixed-length sprints minimize that gap by bringing the product manager and engineers together at a fixed interval. The findings at each sprint guide the Scrum team to incorporate the required changes before the particular task is done, tested & documented.  5. Maximizes Responsiveness to Customer Fixed-length sprints improve the responsiveness to customer requests. True, instant turnaround to customer requests is not possible; yet, it can be addressed quickly at priority. The only way to satisfying the customer at the best is to deliver the new feature or to fix the bug quickly in short fixed-length sprint cycles.  How to Fix the Ideal Sprint Length – 5 Tips:   Ideally, sprint is a fixed time period of 1-4 weeks; it depends upon the team to schedule the sprint. The shorter Sprints spanned for one - two weeks help the Scrum teams identify the problems faster; but sometimes it seems uncomfortable. Many times, Scrum teams decide for the 3 - 4 weeks longer sprints to avoid indulgence towards these problems/ impediments; however, it is not a Scrum-like approach because Scrum principles guide to identify and deal with the problems at the earliest. So, the question is how to fix the ideal sprint length holding the balance between focus and opportunistic adaptiveness. The following 5 tips will help you optimize the sprints schedule:    1. Uncertainty may come in a variety of forms like not properly defined requirements, new technology, high-risk potential, difficult-to-implement interface etc. In case of significant uncertainty, you should go for shorter sprints - the most effective way to refine the project requirements or to try the new technology before getting set for solution development.  2. The volume of tasks and the expected time required affect the selection of sprint length. The team members should be comfortable to accomplish the task to complete a user story during the gap between the two sprints; and, as a Scrum Master, you should have a fair idea of the time required.     3. If you are facing a lot of disruptions, shorten the Sprint length to match the occurrence of disruptions.   4. The project duration is the key deciding factor for Scrum sprint duration. A short-period project such as one of three-month benefits from shorter sprints because of more reviews at shorter periods. If the project is long in duration, continue to look at the other factors. 5. Each Scrum sprint provides an opportunity to the Scrum Master to document the progress to stakeholders. Each sprint provides an opportunity to stakeholders to request for revisions. If you expect the stakeholders to provide input, prefer to set shorter periods for the sprints.   Setting your iterations too short in #scrum can have a damaging effect. "Failed" sprints and poor morale. #agile #teams — John Cutler (@johncutlefish) June 10, 2017 Concluding Thoughts:  Shorter Sprints are preferred because of many reasons as discussed above but these need to be scheduled perfectly at comfortable intervals so that the sprint planning, sprint reviewing, sprint retrospective can be meaningful. Instead of fixing the sprint length to fit the ‘Product Backlog Items’ size, it is better to make the items smaller. The Certifications like CSM and other project management training and courses provide the deep insights into the perfect sprint planning.  
Rated 4.0/5 based on 43 customer reviews
5 Reasons To Have Fixed-Length Sprints

Should the sprint length in Scrum be fixed or vari... Read More

Useful links