Chapter 03 - Scrum Aspects

19. Factors

When we consider the overall factors that go into business justification of a solution, it really looks like a typical business case template. This, of course, begins with the reason for the project. What is it that's happening in the business environment that drives the need for this particular solution? Solution or product? What's happening inside the organization? Relative strengths and weaknesses? What's happening outside the organization? Potential opportunities, potential threats, and risks that need to be mitigated? And, in light of all of this, what exactly is the business requirement? Notice I'm not saying how will we do it or what exactly should we provision, but what is the need that the business would really like? This helps us to structure the general benefits that we seek to see from the project. The relative costs of the project, and any opportunity costs associated with it, Identifying major risks and the desired time scale for the project Project time scales may change depending on changes that are desired by customers, changes that are identified based on potential risks that need to be mitigated, and so forth.

20. Business Justification and the Project Lifecycle

As we work our way through the project's lifecycle, We want to be able to ensure we have an appropriate, justified business case that continues throughout the project timeline. So we may use a business case on the frontend to justify the creation of a project, the formation of a team, and the beginnings of work. Right, but we want to be able to demonstrate, as we work our way through each sprint, that there's continual justification based on the value that is being produced, based on the deliverables from the project team, and how that then demonstrates in benefits realization, after each release, that the team is continuing to produce high-value solutions that are delivering the optimizedbenefit for the customer.

21. Business Justification Techniques

Now there are a number of different techniques we're going to use to be able to look at business justification in various forms. We can use traditional financial metrics like return on investment net, present value, or internal rate of return. We can use techniques like Value Stream Mapping to look at how various features and activities drive the overall value of a solution in terms of business value achieved. We can use a number of different value-based prioritisation techniques. We've got techniques like Moscow Analysis, monopoly money, hundred pointmethod, and canoe analysis, which we'll look at in more detail in just a few minutes. Based on all of this, we want to be able to do a relative prioritisation given all the things we like, which things are the most important, and it's really the job of the product owner to specify in the prioritised product backlog exactly what it is they would like 1st, 2nd, or 3rd given their drugs. And then it's really our job to help them identify at which segments or stages of that we'd meet what we'll call minimum marketable features or minimum functionality sufficient to be able to release a solution that's going to be usable and useful to our customers and users of the service. Lastly, there are a number of other techniques out there for doing this, including things like story mapping, using various mapping techniques to describe exactly what it is that a particular solution might drive value to the enterprise.

22. MoSCoW Analysis

Let's take a look at some of the specific techniques you might use for prioritisation of activities within effort. One of the ones you may facilitate many times as a scrum master is called a Moscow analysis. Given a set of requirements or a set of user stories, which ones are the most important? Of course, keep in mind that many customers begin with the idea that all requirements are mandatory. Understand that this implies that all requirements are equal and that any requirement is as good as any other requirement. That's simply not true in almost any circumstance. There are prioritizations. Now I may need certain pieces of them in order to get meaningful value from them. So that's the minimum marketable features, and that's something else. But I want to make sure that we prioritise the level of effort based on the things that are the most important to the business. So one of the fundamental ways to do this that you'll see in many methodologies, not just Agile methodologies, but service management methodologies like Idle and many others, is to use a service management methodology. Include the concept of a Moscow analysis. m is formusthaves or must do's. These mean what they say Is this required, or is the solution ineffective?

Okay, so I must have requirement means what it says. I really, truly must have this or I can't use the solution I should have. As the name implies, this means that I really should have this as a solution. In order for a solution not to be defective or somehow missing deep and fundamental parts of it, it should have this particular feature or capability. It is desirable. It's nice to have, but it's nice to have not need to have, and so, relative to the others, this isn't quite as critical. But it doesn't mean we don't want it or that it wouldn't be really exciting to have it. It just means that, relative to these other requirements, it's something that is less mission critical to the overall success of the project. Finally, won't have or would have described to have that are simply not as important as the others and are unlikely to occur within a reasonable timeframe based on the prioritisation schema. These tend to end up at the end of your product backlog, and they may never end up getting developed because you may have ended up in a situation where you identify changes. New features that may end up continually coming in ahead of these would have never in fact ended up getting done in many cases because they're just not as important as the other things that we're doing.

23. 100 -Point Method

Another of the techniques we use to priorities is what's called the 100 point method. When you're working with users and customers to look at particular user stories, eventually you have to have them prioritize. Which of these stories needs to go 1st, 2nd, or 3rd in the prioritized product backlog? So this is essentially a riff on multiple voting techniques, and what you want to do is provide everybody with 100 points. They can allocate across all of the user stories that have been identified by the customer. They can vote for and provide any number of points to any user story they prefer. But we'll use the aggregated point total identified by the teams to help drive the prioritization of the overall product backlog.

Study with ExamSnap to prepare for GAQM CSM Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, GAQM CSM Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide GAQM CSM Practice Test Questions & Exam Dumps that are up-to-date.