## The Agile Manifesto — [https://agilemanifesto.org/](https://agilemanifesto.org/) - Individuals and Interactions instead over Processes and Tools - Working Product over Comprehensive Documentation - Customer Collaboration over Contract Negotiation - Responding to change over Following a Plan > [!info] While the items on the right are important, they should not be prioritized over the items on the left ## What does a Scum team look like? ![[Untitled.png]] Everyone that is apart of the scrum team is considered a developer. Everyone should be able to do anything that their skillset allows them to do whether that be testing, architecting, or something else. ## Scrum Process Flow ![[Untitled 1.png]] - Product Owner - The primary communication point between the team and the stakeholders. - They set the priorities for the team and what they should focus their efforts on - Scrum Master - Help guide the team to ensure the scrum process is being followed - Product Backlog — Artifact - A list of all user stories that the team needs to work on - A user story is just a requirement for the project that needs to be completed - Sprint Planning Meeting — Ceremony - Happens at the beginning at the start of a sprint (between 1 to 4 weeks, no more or less) - Sprint Backlog — Artifact - Consists of a list of tasks based on user stories. To do this, you break down each user story into individual requirements and smaller 1-2 day tasks - This will occur in a sprint planning meeting - Daily Scrum Meeting — Ceremony - Just a meeting between the scrum master and the developers to get status on what is going on - Product owners and above should _**not**_ be allowed into this meeting - Sprint Retrospective — Ceremony - Happens usually after every sprint (every 2 weeks on average) - The team demonstrates what they worked on and shows off the work to the product owner and stakeholders ### Scrum is......... A framework to address complex adaptive problems while ensuring the highest possible value in delivering products and ensuring productivity and creativity. - Lightweight - Simple to understand - Difficult to master ![[Untitled 2.png]] ## Scrum Theory - Founded on the Empirical Process Control Theory - Knowledge comes from Experience - You make decisions based on what you know - Scrum employs iterative, incremental approach to optimize predictability and control risk ### 3 Pillars of Empirical Process Control Plan —> Do —> Inspect —> Act - Transparency - Inspection - Adaption >[!caution] WILL BE ON THE EXAM # Sprints ### Rules - At the end of a sprint, the product should be potentially shippable - At least some new features or functions have been taken from an idea and been implemented - The team includes everyone needed to accomplish this ### What do we mean by potentially shippable? At the end of a sprint, everything should be _potentially_ shippable. This mean the work is.... - It is completed - Has been tested - High quality of work - Accepted by the Product Owner ![[Untitled 24.webp]] ![[Untitled 1 1.webp]]The answer is yes! Just because it is not ready for productions, does not mean that it isn’t considered potentially shippable. ### Always delivery! You must ALWAYS have a potentially shippable product at the end of a sprint. **DO NOT MISS THIS** - The deadline is sacred - Drop scope if needed - Dropping scope from the sprint is not the same as dropping it from your planned release ![[Untitled 2 1.webp]] Listen to the product owner. Even if the team does not agree with the level of quality, the product owner is ultimately responsible for the work. They have more information in most cases and ultimately, are responsible for the prioritization of the work. ## What Does “Done” Mean? - Varies _**SIGNIFIGANTLY**_ per team and can change over time - Members should have a shared understanding of what it means for work to be completed - The purpose of each sprint is to deliver increments of potentially releasable functionality that adhere to the team’s current definition of done ![[Untitled 3 1.webp]] Just because you run out of time to preform all the steps required for the definition of done to be met, does not mean you are allowed to skip or side-line items in the flow. In this instance, you should drop items from scope to finish your sprint on time ![[Untitled 4 1.webp]] _(note the yellow is architecture, not red)_ With Scrum, your first sprints are going to be very heavy on the architecture site of things with very little development happening. You won’t be doing ALL of the architecture at first, but in order to start building out the structure it’s going to more of that then development. As time goes on, the amount of time needed to plan and architecture will shirk as the team’s experience with the product progresses ![[Untitled 5 1.webp]] ![[Untitled 6 1.webp]] Releases should ideally be made frequently when using scrum to allow for smoothing out the intensity and volatility of the project. ## Reciprocal Commitments Team will commit to delivering some amount of functionality. The business in turn then agrees to not change those commitments or priorities during the sprint. No changes should occur during the sprint in regards to what was committed to and the product owner agrees with. Even if the initial commitment is vague, it is the job of the team and scrum master to define these commitments in the sprint planning meeting. If there is a change, there is a process for this called...... ### Abnormal Termination This is for extreme circumstances only and is not often used. Since most sprints only last two weeks, it should always be asked if the process change can hold for two weeks. If the business can’t wait that long, then the termination is acceptable. The team itself can also agree to terminate as well if they feel they cannot meet the sprint goal. The product owner can also do so if the business changes priorities. Having shorter sprint can help avoid situations like this. When an termination occurs, all the unfinished work is reversed/undone. The code should revert to where it was effective at the end of the previous sprint and a new sprint planning should occur with the new business priorities in mind. ## Questions about Sprints - Is there such thing as an analysis sprint for purely gathering requirements? - Nope! You will be doing your analysis work as apart of your sprints - You will never do a full stop of work for just analysis with zero development happening - Likewise, there is no such thing as a testing sprint - What is a hardening sprint? - This sprint is used to clean up the code and product to ensure quality of work - To do this, just create user stories for each item you want to “harden” - What is a release sprint? - Always target a potentially shippable product increment - Some polishing can occur in a polishing or release sprint. Some items that you may find in these sprints are..... - Mean Time Between Failure testing - Stress, Performance, Usability testing - Compliance testing - Documentation touch ups # Product Backlog 1. Prioritizes list of features 2. Prioritized by the Product Owner 3. Reprioritized at the start of each sprint 4. Each item should be valuable to users or customers 5. These are _**NOT**_ developer stories ![[Untitled 7 1.webp]] ## User Stories Follow the three Cs........... - Card - Stories are traditionally written on index cards - May be annotated notes, but is not a fully fleshed out out idea - Conversation - Details emerge on what is needed via talking with the product owner - Confirmation - Define acceptance tests to ensure the needs are met ### How do I format user stories? >[!note] As a [user role], I want to [do something], so that [reasoning] Examples of this would be....... - As a frequent flyer, I want to see my points, so that I know when to cash them in for free flights - As a checking account holder, I want to categories my transactions, so that I can analyze my spending habits In order to add in some specific business needs and technical details, we would do this as such - As a frequent flyer, I want to view my itinerary even if there are 50k other concurrent users, so that I know when my flight departs - As a checking account holder, I want my transaction history to display within 3 seconds, so that I don’t get frustrated and bank somewhere else ### Breaking down the criteria even further! ![[Untitled 8 1.webp]] >[!hint] You do not have to format the user stories in the format listed above, but for this class it is a good example. As long as you include all three portions of the story you are good to go ## Stocking the Product Backlog Ideally, you want to build and write out the entire backlog before the first sprint or during the first two sprints. This is helpful for planning your releases, setting expectations, and influencing design/code decisions. You will want to write out smaller stories for sprints happening sooner, while larger stories to be worked on later. The team should have story grooming meetings with the product owner to determine the size of the stories and break them down if needed before sprints occur. ![[Untitled 13 1.webp]] ![[Untitled 14 1.webp]] ![[Untitled 15 1.webp]] ![[Untitled 16 1.webp]] ![[Untitled 17 1.webp]] ### INVEST in your User Stories! - Independent - Ensure everything needed to accomplish the story is already there - Negotiable - Valuable - The story needs to be valuable to the customer - Estimable - If the story is too big in size to estimate, the story needs to be broken down - Small - If something is going to be done in an upcoming sprint, it needs to be fully defined and acceptable size to be completed in a sprint with an AC - Testable #### Slides ![[Untitled 18 1.webp]] ![[Untitled 19 1.webp]] # Product Owner and Scrum Master > [!abstract] As a reminder, everyone that is apart of the team that is doing the work is considered a developer! No one person should be able to only do one thing on the project ![[Untitled 9 1.webp]] ## Product Owner Is responsible for maximizing the value of the product and the work of the development team. They are a single person and not a committee and is the sole person accountable for managing the Product Backlog. ![[Untitled 10 1.webp]] ![[Untitled 11 1.webp]] ## Scrum Master They ensure the scrum is understood/enacted and maintain the scrum theory, practices and rules. Additionally, the provides the following: - Find techniques for effective backlog management for the product owner - Assists scrum team understand the need for clean and concise backlog items - Understand the product planning empirical environment - Assists with communicating what needs to be done coding wise to accomplish goals ![[Untitled 12 1.webp]] ![[Untitled 20 1.webp]] ![[Untitled 22 1.webp]] It’s time for an exercise! Time to solve the following issue: ![[Untitled 23 1.webp]] # The Team - They consist of professionals who do the work of delivering a potentially releasable increment of done product at the end of each sprint. - Only members of the development team create the increment. They are in charge of how they accomplish their own work - Dev Teams are structured and empowered by the company to organize and manage their own work - The resulting synergy optimizes the team’s overall efficiently and effectiveness ![[Untitled 24.webp]] ![[Untitled 2 1.webp]] ![[Untitled 3 1.webp]] > [!info] Don't forget! > New team members should be help to being added after a sprint ends ![[Untitled 4 1.webp]] # Sprint Planning The work that will be preformed in the upcoming sprint is decided in this meeting. It is collaborative session between the product owner, scrum master, and developers. This meeting is time-boxed meaning it will last not longer than 8 hours for a month long sprint or 4 hours for a two week sprint (the shorter the sprint, the shorter the meeting). This is to ensure value is focused and time is not wasted on less valuable items. The time is up to the team, but no matter what 8 hours is the absolute max. The scrum master ensures the vent takes place and everyone understands it’s purpose. They do not always need to attend these meetings, but they do need to ensure the developers know what they should be doing in the meeting. The timebox should be valued above the scope, so even if more planning is needed to define scope, that scope should be held off till the next planning meeting > [!tip] These meetings should focus on answering two questions: > 1. What can be delivered? > 2. How will it get done? ## What can be delivered? - The dev team will “forecast” the functionality that will be developed in the sprint - The product owner discusses the objective for the sprint and what it should achieve. This ties in items from the backlog that need to be accomplished to compete the sprint’s goals; - The entire scrum team collaborates to understand what the scope of the work in the sprint should be. To determine what needs to be done, the following should be taken into account: - The current items in the backlog - The most recent product increment - If anyone on the dev team will be out or if their capacity will be limited - The velocity of the dev team can accomplish historically each sprint It is up to the dev team to select which items from the backlog that should be done each sprint, not the SM or PO. This is due to them being the only ones who can true access what they can accomplish each sprint ## Sprint Goals Once the dev team forecasts the backlog items they will be working on, the scrum team should craft themselves a goal. This goal is an objected that will be met within the sprint through the implementation of the backlog. In doing this, it provides guidance to the team on why they are building out each task and gives them flexibility. >[!info] >This is different from what the project owner comes in with saying they want to prioritize. The goal is defined around what work _can_ get some based on you have agreeded about in your forecast. If you end up needing to drop tasks, this will provide guidance on what can be dropped in scope but still meet your goals. ![[Untitled 5 1.webp]] >[!abstract] Remember! Accuracy should always come over precision ## Sprint Backlog Unlike the product backlog, this is used to plan out what work should be done within the start of the sprint and guide their progress. Items from the product backlog should be pulled into the sprint backlog and prioritized in your planning meetings. ## Business Trade-off Decisions It is up to the product owner to clarify items in the backlog and identity any trade-offs in it. If the dev team has too much or too little work, it is up to them alert and to renegotiate the backlog items with the project owner. They can also invite others to planning meetings should they provide additional insight or advice that may be seen as helpful By the end of the planning session, the dev team should be able to explain to the PO and SM how they intend to work to accomplish the goals of the sprint and create an potential release increment. Transparency is critical and one of the 3 main pillars of scrum. ![[Untitled 6 1.webp]] Question time? How would you deal with the following situation? ![[Untitled 7 1.webp]] To answer the final question, the answer is no. When figuring out timing and assignments, the work should not be seen as “x person will do y in z time”. Instead, it should be viewed as a team effort and the team will collectively make a decision on pointing. Even if the most experienced team member is out, that doesn’t mean only they can do the work and estimate. Everyone should be apart of this process >[!info] Take note! >Once you start actually pulling work into the sprint, then you can start assigning tasks to developers. These choices should _**NOT**_ be done in initial planning ![[Untitled 8 1.webp]] After the meeting, the backlog for the sprint needs to keep the following items in mind: - Estimates of work _**remaining**_ should be updated daily - Any developer can add, delete, or change the sprint backlog - The sprint backlog should be defined with your best guess and continuously updates and refined as the sprint progresses - As more information becomes know about the work remaining, updates to those tasks should be made If at any point work needs to be removed, some key things must happen and be kept in mind: - The sprint goal must not be effected by the removal of work - The product owner should be notified and developers should negotiate with them on can can/can’t be removed # Release Planning ![[Untitled 9 1.webp]] ![[Untitled 10 1.webp]] ## What is Velocity? Velocity is a long term measurement of the amount of work _**completed**_ in a sprint. This does not go over the amount of time worked or the effort spent on work that not completed in that sprint. You do not track this in time, but rather in points used to convey value/effort ![[Untitled 11 1.webp]] ### How do we measure this? There are two different metrics commonly used. They are: - Story Points - Usually based on relative sizing and how the team operates - Points are assigned based on the Fibonacci Sequence - Once you hit 13, you usually go up by round numbers - Some teams however will do 18, 25, 45, ....... - Ideal Time - The amount of time likely to accomplish a task by a single person uninterrupted - Often expressed in days not hours # Tracking Progress ![[Untitled 12 1.webp]] ![[Untitled 13 1.webp]] ![[Untitled 14 1.webp]] # Meetings ## Daily Scrum This is a 15 minute MAX time-boxed event held at the same time/location to reduce complexity. Only the development team needs to be in attendance for this meetings. The goal of the meeting is to inspect the work completed in the past 24 hours and plan the next 24. To accomplish this, three questions should be asked of each member: - What did I do yesterday that helped the dev team meet the sprint goal? - What will I do today to help the dev team meet the sprint goal? - Do I see any impediment that prevents me or the dev team from meeting the sprint goal? ![[Untitled 15 1.webp]] ![[Untitled 16 1.webp]] ![[Untitled 17 1.webp]] ![[Untitled 18 1.webp]] ## Sprint Review This is a 4 hours time-boxed meeting with a max of 2 hours of prep. This shall be held at the end of every sprint and is an informal meeting and is _**NOT**_ a status meeting. Based on this meeting, the scrum team and stakeholders can inspect the product increment and adapt the product backlog if needed. The primary purpose of this meeting is as follows: - Elicit feedback and foster collaboration - Revise the product backlog to meet new opportunities - Provides feedback and transparency for the team to inspect and adapt in order to optimize the business’s value. This falls to the project manager mainly In this ceremony, the SM is charge of the following: - Ensures the event takes place - Ensures the attendants understand it’s purpose - Ensures the team WORKING software and not a slide deck - Enforces the time-box - Should the time run out, the meeting should end and not be continued without exception ### Additional Rules: ![[Untitled 19 1.webp]] ![[Untitled 20 1.webp]] ## Retrospective This is a 3 hour time-boxed meeting for 1 month sprints (shorter for shorter sprints). This is help after the sprint review but before the next sprint planning session. Within this meeting, the scrum team will evaluate itself and create a plan for how to improve going forward. ![[Untitled 21 1.webp]] # Scalability ![[Untitled 22 1.webp]] ![[Untitled 23 1.webp]] ![[Untitled 24 1.webp]]