Business Requirements and Project I Assignment - Tagged PDF

Scrum Process Business Requirements Project Assignment CSPC 541 Fall 2024 Prof. Son Nguyen Welcome – Week 3  Attendance/Sign In to the attendance sheet  Review – SDLC and Requirements Engineering (OYO)  Agile/Scrum Process  Business...

Scrum Process Business Requirements Project Assignment CSPC 541 Fall 2024 Prof. Son Nguyen Welcome – Week 3  Attendance/Sign In to the attendance sheet  Review – SDLC and Requirements Engineering (OYO)  Agile/Scrum Process  Business Requirements (Chapter 5)  Project I Assignment  Coming Next  Q&A  What is Scrum? 1. Have you heard of Scrum? 2. Have you had any experiences with Scrum?  If you do, where are your experiences coming from (classroom/work) 3  What is Scrum?  Scrum is one of the framework under the Agile software development.  The term “Scrum” was first used by Hirotaka Takeuchi and Ikujiro Nonaka in their ground-breaking 1986 paper “ The New New Product Development Game”.  They borrowed the name from the game of rugby to stress the importance of teams in complex product development  “Scrum is a management and control process that cuts through complexity to focus on building software to meet business needs. Scrum is superimposed on top of and wraps existing engineering practices, development methodologies and standards” [Schwaber 2002] 4 What is Scrum?  Scrum focuses on: ◦ Content of an iteration (Sprint) ◦ Prioritized requirements to be considered in iteration (Sprint Backlog) ◦ A Short daily meeting (a Scrum meeting)  A major theme in Scrum is “inspect and adapt.” ◦ Scrum emphasizes taking a short step of development, inspecting the resulting product Did it meet expectations? ◦ and the efficacy of current practices How can we work better or make the product better? ◦ and then adapting the product goals and process practices Is this still the most valuable feature to deliver at this time? ◦ Repeat forever!!!!! 5 6 7 Scrum Roles - Team  In Scrum, there are three roles: ◦ Product Owner ◦ Scrum Master ◦ Team  Together these are known as the Scrum Team or Development Team  Responsible for actual doing of the work building the product (e.g. the application or website) that the Product Owner indicates : ◦ Team shows work at close of an iteration or Sprint  Team size of 5-9 individuals ◦ Full-time, dedicated, cross-functional (i.e., each member can build and test) ◦ it includes all the expertise in analysis, development, testing, interface design, database design, architecture, documentation, etc. necessary to deliver the potentially shippable product each Sprint ◦ demonstrates multi-learning: each person certainly has special strengths, but also continues to learn other specialties.  Team-directed / Team-managed (self-managed)  For the class project, you will be member of a Scrum team (5-6 members) 9 Scrum Roles: Product Owner Responsible for maximizing return on investment (ROI) by: Identifying product features Translating these into a prioritized features list called Product Backlog Deciding which should be at the top of the list for the next iteration or Sprint continually re-prioritizing and refining the list. Ultimate responsibility and authority – Interfaces to the customer – Controls budget/Has profit/loss responsibility – Develops product vision and conveys the vision to the team – Determines when a feature is done (validates product quality)  Single person, not a committee  Be available to the team  For the class project, each team to designate a Product Owner 10 Scrum Roles: Scrum Master Facilitates the Scrum Framework – Upholds Scrum values and practices (commitment, focus, openness respect, and courage) – Facilitates the Scrum Meetings – Typically, not doing the development work Helps the Team be as efficient as possible and be successful ◦ Is a coach and a teacher, NOT a manager ◦ Protects the team from outside interference (i.e., the firewall for the Team) ◦ Facilitates continuous improvement ◦ Helps remove barriers (roadblocks)  There should be a dedicated full-time Scrum Master, although a smaller Team might have a team member play this role (carrying a lighter load of regular work when they do so)  For the class project, each team to designate a Scrum Master (SM)  Only PO/SM can interface with the customer (i.e., the professor) 11 Teamwork  Self-organized  Entire team (including the Scrum Master) is collectively responsible for completing the work ◦ Total team head count should be from 5-9 members  Collaborate work among team members and commit to delivery of the sprint backlog (i.e., build the product increments) ◦ Team chooses their own tasking ◦ Team members help each other succeed  Continuous attention to technical excellence and good design enhances agility  Focus on communication, simplicity, feedback, and courage 12 Scrum Process Overview Example: Bill (PO) meets with customers to discuss their company’s needs. Those needs are the product backlog. Bill and his team choose the most important tasks to work on in the next two weeks. His team meets in a daily scrum to target work for the day ahead and address roadblocks. At the end of the sprint, his team delivers the work after a successful review/demo, performs retrospective, reviews the backlog, and sets the goal for the next sprint. The cycle repeats until the software is complete. ( for one iteration/Sprint) Product Plannin Design g Coding Test 13 Scrum – another view 14  Product Planning Participants: – Some Team members, Scrum Master, Product Owner, Stakeholders Purpose: – Create initial sprint plans (typically occurs early in project planning) – Helps Product Owner understand impact of estimates and schedule Output: – Healthy Product Backlog containing item descriptions, Priorities, and estimates 15  Product Backlog  Prioritized list of everything that is needed in the product (vision) Requirements, ideas, requests, desires  Single source of product requirements  Always changing ◦ Items are added, removed, and reprioritized based on value Prioritized  The product is built incrementally based on worked selected from List of features or “user stories” that product needs the backlog 16  Stories in the Product Backlog  Features and requirements are tracked as stories (similar to use cases) in the Product Backlog  Written it from the user’s perspective  Sample user story structures: ◦ As a , I want , so that ◦ Given a certain situation, when this condition occurs, then this is the functionality the user will experience. ◦ As a developer, I want a build server installed so that I can continuously integrate my software ◦ As a customer, I want my credit card information to be stored, so that I save time when checking out.”  Epic: A user story covers large amounts of functionality.  An epic is generally too large for a Scrum team to complete in one Sprint, it is split into multiple smaller user stories 17 Stories in the Product Backlog  The Product Owner manages priorities of stories in the Product Backlog  Each story must contain a unique id, a description, priority, and estimate, and completion criteria recommended  The Product Owner owns the Product Backlog 18 A user story 19 Sprint Planning- Part 1 “The What” Participants: – Team, Scrum Master, Product Owner Purpose: – Team and Product Owner discuss the product vision – Review and update the high-priority items in Product Backlog – Provide the Goal for the coming Sprint – Select items from Product Backlog to place in Sprint Backlog Output: – List of Stories the Team will be able to complete during the Sprint – Re-Prioritized Product Backlog – Each high priority item is a good story 20 Sprint Planning- Part 2 “The How” Participants: – The Team and Scrum Master Purpose: – Break the Stories into detailed tasks for how to accomplish the Sprint goal – Discuss and select the work from Sprint backlog the Product Backlog – Agree on size estimates – Team members choose their work (it’s not assigned – Make the final commitment to complete by the end of Sprint Output: – Sprint Backlog: Tasks are identified, estimated (in hours/points), and “assigned” – The Plan For the class project, team to perform Sprint Planning Part 1/2. 21 Sprint Backlog- an example Sanja Jying Tracy/Sarah Sarah Sanjay/Jing Scrum Primer V2.0, 2012 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde 22 The Daily Scrum Daily, 15 minutes, Stand-up * Participants: – The Team, Scrum Master, Product Owner – Stakeholders (Listen only!) Purpose: – Answer three questions: 1. What did I do since the last Daily Scrum? 2. What will I do before the next Daily Scrum? 3. What roadblocks stand in the way? http://ayagebeely.blogspot.com/2009/10/stand-up-meeting.html – Provide coordination mechanism for The Team – Not a status or problem-solving meeting – Inspect & Adapt opportunity  Input: Updated Sprint Backlog and Sprint Burndown  Output: Updated Task Board & Burndown * For the class project, team needs to have a Scrum Meeting on a regular basis. SM to keep track of team member participation 23 The Sprint Burndown Plot depicting the remaining work on the Sprint Evaluates work left to be done in the Sprint on a daily basis Indicates risk of Sprint completion failure Will all work assigned to the Sprint be completed by the end of the Sprint? 3 Scrum Primer V2.0, 2012 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde 24 Tools to Help Track Progress IBM Relational Team Concert, Atlassian Jira Software Microsoft Teams, SharePoint, Excel, etc. Open Source: Trello, Icescrum, Taiga, Scrumpy, etc. Physical Task Board http://ayagebeely.blogspot.com/2009/10/stand-up-meeting.html Nomad8.com For the class project, team to select tool(s) to keep track progress 25 Sprint Release/Product Increment Contains work products of the sprint (demonstrated/reviewed during Sprint review) Must meet the “definition of done” established during sprint planning Under configuration management control. Why is it important? Sprint build release (engineering build) Capable of being formalized 26  Sprint Retrospective Done after every Sprint Participants: – The Scrum Team, possibly Stakeholders and others Purpose: The whole team – Evaluate what is and what is not working – Discuss what they would like to start doing/stop doing/continue doing – Plan ways to improve – Inspect & Adapt opportunity – for the sake of the Program Typically, 3 hours or less Output: – Document lesson learned – Ways to improve as a team May be a change to process A Story/Task added to the Product Backlog  For the class projects, team to conduct a Sprint Retrospective after each project (or Sprint) 27  Agile Estimation  Stories in the Product Backlog must have estimates – At least the top 20% highest priority items – Done during Product Planning and/or Sprint Planning I  For effort estimates, a common technique is to estimate in terms of relative size (factoring in effort, complexity, risk, and uncertainty) of a feature using a unit of “story points” or simply “points”. ◦ Select one of the smallest stories (e.g., a small piece of code of 10 SLOCs, a small test script to be written) and give it an estimate of 1 story point ◦ Each additional story is estimated by relatively comparing to the first story or to any other that have been estimated  Agile Estimation: Velocity  Another common technique used in Agile/Scrum is to track how much work the team completes each Sprint  Velocity is a measure of a team’s rate of progress.  It is calculated by summing the number of story points that the team completed during the iteration  On a “stable” team the velocity will eventually converge on a consistent value 29 Agile Estimation -Example  Product Backlog estimated at 800 Story points  The Team velocity per Sprint is 100 Story Points  800/100 = 8 Sprints  If each Sprint is 4 weeks, then we will need 32 weeks to complete the entire project Scrum of Scrums  Used to scale Agile ◦ When teams are > 12 members ◦ Scrum has been used on projects of over 1,000 people Ambassador ◦ Each team selects an ambassador  Report on each team ◦ Completion ◦ Next steps ◦ roadblocks https://www.6kites.com/scrum-of-scrums  Resolve coordination challenges between teams  Scrum of scrums has its own backlog these items  May meet a few times per week  There is also a scrum of scrum of scrums!  Large-scale Scrum (LeSS) – LeSS is a set of rules combined with guides for applying Scrum in a multi-team context. 31 Scrum – common challenges  Scrum works by making visible the dysfunction and impediments that are impacting the Product Owner and the Team’s effectiveness, so that they can be addressed  For example, committed stories vs. delivered results ◦ If a team commits to 100 story points at the beginning of a four-week sprint but they deliver only 80, then the team is not meeting their commitments to themselves, business, or the customer. The release will instead be put on hold and pushed to next release ◦ To the Team, this feels like failure. But in reality, this experience is the necessary first step toward becoming more realistic and thoughtful about its forecasts (task analysis, estimation skill).  This pattern of (Scrum helping make visible dysfunction, enabling the Team to do something about it) – is the basic mechanism that produces the most significant benefits that Teams using Scrum experience. Summary  Scrum creates an environment that: ◦ Expects and promotes self-m….. teams: P…O…., S…. M…, Team ◦ Provides frequent opportunities to I…… and A…..  Daily Scrum, Sprint Review, Retrospective, etc. ◦ Enhances communication between the Stakeholders and the Team  short iterative full-cycle feedback loops called S….. ◦ Enables continuous imp…….  Always looking to be better as a team and deliver better product  and lowering the cost of change  These concepts increase agility and feedback, enable earlier ROI, and reduce r…. 33 Just a few more slides, let’s take a short break! https://www.dreamstime.com/illustration/take-break.html Establish the Business Requirements CPSC 541 Fall 2024 Prof. Son Nguyen Business Requirements  Business requirements represent the top of the requirements chain  They define ◦ the vision of the solution ◦ and the scope of the project that will implement the solution  The user requirements and functional requirements must align with the context and objectives that the business requirements establish  Business Requirements  Requirements that don’t help the project achieve its business objectives shouldn’t be implemented  A project without a clearly defined and well-communicated direction invites disaster.  This lecture describes the vision and scope document, a deliverable that contains the project’s business requirements  Review: Business  Requirements Business requirement – A high-level business objective of the organization that builds a product or of a customer who procures/requests it ◦ Business requirements describe  why the organization is implementing the system  the business benefits the organization hopes to achieve  Example: An airline wants to reduce airport counter staff costs by 25 percent. This goal might lead to the idea of building a kiosk that passengers can use to check in for their flights at the airport. Review: Business Requirements  Business requirements typically come from the funding sponsor for a project, the acquiring customer, the manager of the actual users, the marketing department, or a product visionary. ◦ Business requirements are recorded in a vision and scope document.  Other strategic guiding documents sometimes used for this purpose include a project charter, business case, and market (or marketing) requirements document. 3 Define business requirements  Identify desired business benefits ◦ Business requirements might come from funding sponsors, corporate executives, marketing managers, or product visionaries ◦ It can be challenging to identify and communicate the business benefits  Team members sometimes aren’t exactly sure what the project is intended to accomplish.  Sometimes, sponsors don’t want to set objectives in a measurable fashion and then be held accountable for achieving them  There could be multiple important stakeholders who don’t agree on what the objectives should be ◦ The business analyst can ensure that the right stakeholders are setting the business requirements and facilitate elicitation, prioritization, and conflict resolution Define business requirements  Identify desired business benefits (cont.) ◦ The business benefit has to represent a true value for the project’s sponsors and to the product’s customers.  For example, simply merging two systems into one is not a reasonable business objective.  Customers don’t care if they are using an application that involves 1, 5, or even 10 systems.  They care about issues like increasing revenue and decreasing costs.  Merging two systems might be part of the solution, but it is rarely the true business objective ◦ Regulatory and legal compliance projects for software development for Banking and Telecom industry clients also have clear business objectives ◦ Often the objectives are phrased as risk avoidance, possibly to avoid getting sued or being put out of business Product Vision and Scope  Two core business requirements elements: ◦ Product vision ◦ Project scope  The product vision briefly and clearly describes the ultimate product that will achieve the business objectives ◦ This product could serve as the complete solution for the business requirements or as just a portion of the solution ◦ ◦ The vision describes what the product is about and what it ultimately could become. ◦ It provides the context for making decisions throughout the product’s life, and it aligns all stakeholders in a common direction ◦ Examples- Amazon - To be Earth's most customer-centric company, where customers can find and discover anything they might want to buy online. ◦ Apple - To bringing the best user experience to its customers through its innovative hardware, software, and services.  Product Vision and Scope  The project scope identifies what portion of the ultimate product vision the current project or development iteration will address ◦ The statement of scope draws the boundary between what’s in and what’s out for this project  The vision applies to the product as a whole  The product vision encompasses the scope for each planned release, which is less well defined the farther out you look Vision Statement  A concise vision statement that summarizes the long-term purpose and intent of the product.  The vision statement should reflect a balanced view that will satisfy the expectations of diverse stakeholders  It can be somewhat idealistic but should be grounded in the realities of existing or anticipated markets, enterprise architectures, corporate strategic directions, and resource limitations  The following keyword template works well for crafting a product vision statement (Moore 2002): For [target customer] Who [statement of the need or opportunity] The [product name] Is [product category] That [major capabilities, key benefit, compelling reason to buy or use] Unlike [primary competitive alternative, current system, current business process] Our product [statement of primary differentiation and advantages of new product] Vision Statement  Here’s a sample vision statement for the Chemical Tracking System, with the keywords in red:  For scientists who need to request containers of chemicals, the Chemical Tracking System is an information system that will provide a single point of access to the chemical stockroom and to vendors. The system will store the location of every chemical container within the company, the quantity of material remaining in it, and the complete history of each container’s locations and usage. This system will save the company 25 percent on chemical costs in the first year of use by allowing the company to fully exploit chemicals that are already available within the company, dispose of fewer partially used or expired containers, and use a standard chemical purchasing process. Unlike the current manual ordering processes, our product will generate all reports required to comply with federal and state government regulations that require the reporting of chemical usage, storage, and disposal. Document Vision and Scope Vision and Scope Template  Keep in Scope  The project scope defines the concept and range of the proposed solution. It’s also important to define what will not be included in the product.  The business requirements and an understanding of how customers will use the product provide valuable tools for dealing with scope change  Scope change isn’t a bad thing if it helps you steer the project toward satisfying evolving customer needs  The information in the vision and scope document lets you assess whether proposed requirements are appropriate for inclusion in the project.  You can modify the scope for a future iteration or for an entire project if it’s done consciously, by the right people, for the right business reasons, and with understanding and acceptance of the tradeoff  Keep in Scope  Remember, whenever someone requests a new requirement, the analyst needs to ask, “Is this in scope?” 1. One response might be that the proposed requirement is clearly out of scope 2. Another possibility is that the request obviously lies within the defined project scope.  We can incorporate new in-scope requirements in the current project if they are of high priority relative to the other requirements that were already committed  Including new requirements often involves making a decision to defer or cancel other planned requirements, unless you’re willing to extend the project’s duration (impacting cost/schedule) 3. The third possibility is that the proposed new requirement is out of scope, but it’s such a good idea that the scope should be broadened to accommodate it, with corresponding changes in budget, schedule, and/or staff Keep in Scope ◦ When a stakeholder wants to add functionality, consider how the suggested changes will contribute to achieving the business objectives.  For example, a business objective to generate maximum revenue from a kiosk implies the early implementation of features that sell more products or services to the customer. Glitzy features that appeal to only a few technology-hungry customers and don’t contribute to the primary business objective shouldn’t have high priority.  If possible, quantify the contribution the feature makes towards the business objectives, so that people can make scoping decisions on the basis of facts rather than emotions (Beatty and Chen 2012)  Will a specific feature contribute roughly $1,000, $100,000, or $1,000,000 toward a business objective?  We can use quantitative analysis to help determine if adding it is the right business decision.  Keep in Scope  Assessing the impact of scope changes  When the project’s scope increases, the project manager usually will have to renegotiate the planned budget, resources, schedule, and/or staff. Ideally, the original schedule and resources will accommodate a certain amount of change because of thoughtfully included contingency buffers (Wiegers 2007). A common consequence of scope change is that completed activities must be reworked in response to the changes.  Quality often suffers if the allocated resources or time are not increased when new functionality is added.  Documented business requirements make it easier to manage legitimate scope growth as the marketplace or business needs change. Summary  Define business requirements  Product Vision and scope  Keep in scope Coming Next  Team Project assignment will be discussed shortly  Next Week – Week 4 Sep 20 ◦ First Quiz  Will be done in the classroom next week – bring your laptop  Closed book  15 minutes  20 points  Multiple Choice/True-False/Fill-in-Blank questions  Covers from first lecture to Business Requirements ◦ Requirement Elicitation (Chapter 6, 7) 52