SCRUM

Inspection

(Testing and validating the requirements) - Frequently inspect Scrum artifacts and progress - Inspection should not get in the way of the work (we don't have to stop every 10 min. to inspect) - Most beneficial when performed by skilled inspectors during the work

Sprint

- 4 weeks

What is Scrum

- A framework for complex adaptive problems - Lightweight, straight forward set of rules - Simple to understand - Difficult to master

Daily Scrum

- Daily stand up meetings - Daily 15 minute minutes - Scrum master just to make sure the teams answer the questions

Cancelling a Sprintone

- Product Owner has the authority to cancel a Sprint - Can happen when the Sprint Goal becomes obsolete (Changes in the Product Backlog, strategies, or approach) - When a Sprint is cancelled, the items that are "Done" will be reviewed and accepted, and the rest of the items will be put back into the Product Backlog

Three Scrum Pillars: TIA

- Transparency - Inspection - Adaptation

Vision statement

Concise description of the goals of the project

Sprint Backlog

The team takes the user stories and define what tasks have to happen

Scrum Master and Impediments

When there are serious or many impediments: - Alert management to the impediments and impact - Consult with the Development Team - Prioritizing the impediments list and address each in order

Self-Organizing Development Team

(Development team) - Boost to creativity - Team and project commitment (they feel ownership, there is sinergy) - Accuracy of estimates - When new teams are starting a project: (Scrum master more involved in the beginning and then let go, to make people understand the rules of scrum and the definition of done. Team members introduce themselves, their backgrounds, so they can decide who can do the tasks) -- Ensure the team understands they need a definition of done -- Scrum Team members introduce themselves and give a brief background of their skills and work history -- Product Owner discusses the product or project, its history, goals, and context, as well as answer questions

Daily scrum

- 15 minute meeting for the Development Team to inspect the work since the last meeting - Synchronize work and plan for the next 24 hours - Three questions: -- What has been accomplished since the last meeting? -- What will be done before the next meeting? -- What obstacles are in the way? - Team assess progress towards Sprint Goal - Forecasts likelihood of completing items before the Sprint is over - Held at the same time and place throughout the Sprint - For the Development Team; not a status meeting for all stakeholders - Good idea for the Sprint board (wall chart) to be visible - Burn-down chart can be used to track remaining work

Architecture and Infrastructure Concerns

- Added to the Product Backlog and addressed in early Sprints, while always requiring at least some business functionality - Implemented along with functional development of the product - Security, uptime, and non-functional requirements should be added to Product Backlog and Dod

Sprint Retrospective

- After Sprint Review and before the Sprint is over - Development Team holds internal meeting to review the Sprint - Goal is to improve the process (lessons learned) in the next Sprint

Development Team Considerations

- Bring the team together and let them self-organize - Existing teams can propose how they want to organize - Large projects use a scaled model with multiple Scrum Teams -- Multiple Scrum teams are not common -- Adding new Scrum teams wont affect current productivity (because they are already in motion) -- Multiple Dev Teams should be self forming based on vision and Scrum rules -- All teams need a common definition of done -- All teams should have same Sprint starting date

Caracteristics of a Predictive Project

- Clearly defined scope - Clear product description - Historical information from similar projects - Well-defined upfront requirements - Few changes expected - Well-defined activities - Reliable estimates - Process is long-term - Multiple, logical phases - KPIs equate to success - Whole product needed for value

Sprint Backlog

- Created during the Sprint Planning which is the first event in a Sprint - Sprint Backlog includes: -- Number of items selected from the top of the Product Backlog -- Sprint Goal to help describe the real meaning of the items and direct the efforts of the Development Team -- Detailed plan for delivery of the items and realization of the Sprint Goal - Sprint Backlog is frozen after the SPrint Planning - Development Team focuses on delivering and increment of "Done" - Stories in the SPrint backlog cannot be added or removed - Might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner. - Detailed plan will become more complete as the Sprint continues

Comments about Scrum

- Developers live between a framework, they have a set of rules they have to follow, there are goals, the definition of done - The team can't start developing inmediately, their is work that has to be done first. - Not all requirements have to be agreed before Development team can start - Scrum is not easy to implement, it requires training - Scrum is not a simple list of rules, there are some specific rules. - Scrum Master is not like a PM - Scrum does require a business case - The customer decides on deliverables - Product Owner is not the project manager - Product Owner is not a representative from the customer, he is a representative of the business, he works with the customer, with the business - Scrum doesn't tell us everything about managing projects

Sprint Review

- Development Team demonstrates the outcome of the Sprint to the customer - Customer provides feedback to the Development Team - Called Sprint Review (also known as Sprint Demo) - Development team does the demonstration (not the scrum master)

Development team and DoD

- Development team should deliver additional features in a useable state that complement those delivered in previous iterations (you build over what has already been done, you can break what has been created) - If the team can't finish all sprint backlog items: -- They do not include the items in the increment of current Sprint -- They do not show it in the Sprint Review -- They must estimate it and return it to the Product Backlog for the Product Owner to decide what to do with that item (s)

Nature of Scrum Events

- Each scrum project is a set of Sprints - A sprint is a container for the four other events, development effort, and the maintenance of the Product Backlog

Theory of Scrum

- Empirical process control theory, or empiricism (I have experience, I have knowledge and clear understanding of the DoD) - Empiricism asserts that knowledge comes from experience and making decisions based on what is known - Scrum employs an iterative, incremental approach to optimize predictability and control risk

Scrum details

- Evolved since 1990s back with the Agile Manifesto (The Agile philosophy preceded the Agile Manifesto) - Framework for processes, not a process itself - Characteristics of product management, not just project management (our goal is to create the deliverable that the customer wants) - Rules and Roles of Scrum is what you need to know

Sprint Review

- Four hour meeting for a 4 week sprint - Scrum team and other stakeholders - Present and inspect the Done items - Collect feedback and change requests - Development Team does not present an item, it has to be 100% - Product Owner makes sure (before the Scrum Review) that presented items are "Done" - Development team demonstrates and explains the items - Product Owner discusses the status of the Product Backlog and the likely completion dates - Whole Scrum Team collaborates on Product Backlog - If the capacity of the team is less of what they anticipated, this conversation can come up at the sprint review when the product owner discusses the Product Backlog compared to the items done (velocity)

Team Velocity

- How much work did the team get done during a sprint - Velocity is the measure of a team's capacity for work per iteration - Measured in the same unit that the team estimates the work - Velocity very early and then stabilizes - Velocity tends to plateau

Story sizing

- If it's a big or small story - That will define the amount of work that goes into a sprint

Adaptation

- If the resulting product will be unacceptable, the process or the material being processed must be adjusted - Adjustments are made ASAP to minimize additional deviations - Scrum prescribes four formal events for inspection and adaptation: -- Sprint Planning (what are we going to do in this sprint, duration of work) -- Daily Scrum (15 min. meeting, everyone stands up, what have we done yesterday, what are we doing today, are there any impediments to move forward) (Only the develpment team, the scrum master is not required to be there) -- Sprint Review (end of the sprint, what have we done) -- Sprint Retrospective (talk about what worked well, and what didnt, including people, process and product, lessons learned)

Increment details

- Increment is what is appended to the work that we have already done. It is what we have created. - The product increment is the outcome of an iteration (Sprint) - The product increment is a chunk of the project work - The development team and the product owner must agree what done means for an increment - Sum of all completed Product Backlog items at the end of a Sprint - Each increment must be "done" - Must be releasable - Product Owner may/may not release a certain increment

Time box

- It is a fixed period of time - Specific time-boxes in a sprint - Freeze the target and work with full focus on certain tasks or objectives - Duration of a time-box should be agreed upon and fixed - Free to change the duration based on lessons learned, but not frequently, and never based on single occasions (Sprint planning meeting time box is 8 hours for a 4 hour sprint, not development, not retrospective, only planning)

Sprint Planning

- It is the first event in a Sprint - Look at the story sizing, how much work the team can take in - Scrum Team plans the items they are going to deliver in the Sprint (take a chunck of the top items of their backlog and bring it into their sprint) - Scrum Team plans the way they will deliver them (the sizing and capacity) - Mainly between the Product owner and the development team

Sprint Retrospective

- Lessons learned opportunity. Take what we learned and apply it for the next sprint - Attended by the product owner, the scrum master and the development team, what worked and what didnt work. - Three hours for a one-month Sprint - After the Sprint review, and before the end of the Sprint, another meeting will be held, aimed at proces improvement - This is learning lessons and is the Sprint Retrospective - Usually required, but optional if Product Owner, Scrum Master, and Development Team agree. - Always look for ways to improve - Does not matter how little there should be an improvement - Formal opportunity for improvement - Participants reviews (inspects) the Sprint -- People -- Relationships -- Processes and tools -- Identify ways of improvement

Product Backlog

- List of requirements that the Product owner have to prioritize with the development team. - Big listing of everything that the product could have or should have. - Includes functional and non functional requirements - The product owner isn't necesarilly a developer, they are familiar of what the business wants. - The team decides how much of those items they can take in the next sprint. - It's a prioritized list so items at the top have the most value

Product Backlog

- Made up of stories and prioritized by the PRoduct owner and development team - Product owner has the responsibility of keeping it prioritized - When new requirements come, the product owner will prioritize those requirements in the backlog (they could be up top, in the middle or at the bottom)

When to use scrum

- Many unknows (how the screen will look like, all the requirements) - Complex projects with difficult to define detailed requirements - Don't try to apply Scrum if the organization is not ready - Training needed for all Scrum participants

Monitoring Sprint Progress

- Monitor the progress of each SPrint throughout its life - Responsibility of the Development team - Should be done in each Daily Scrum - Used to calculate the likelihood of achieving the Sprint Goal and completing all items of the Sprint Backlog (are we going to be able to reach our Sprint goal, are we going to complete our sprint backlog, if not we have to get our Product Owner involved) - Utilize a Sprint board for transparency -- Sprint burndown chart -- Sprint goal -- Kanban of user stories

Scrum Team

- Only three roles in a Scrum project -- Additional roles harmful to team unity -- Not compatible with Scrum philosophy - Scrum team refers to all the project team members -- Scrum Master -- Product Owner -- Development Team members - Stakeholders can be involved in a project, they are not considered internal - When the project is not internal, the customer is a stakeholder - Always have external stakeholders (the people for what you are creating the product for)

Slack in Scrum

- Opportunity for the team to take a break before they start the next sprint - Does not matter how much the Development team works, what matters is that they are creating deliverables (if nothing is getting done, just because you are busy doesn't mean you are producing) - What is produced is what's important - Team should be product-oriented, not activity-oriented -- Limit the work time to a reasonable amount, and have frequent off times -- Recommened to have a slack between each two Sprints -- A day or two off to recharge batteries -- Read some relevant articles -- Check out what other teams are doing - Slacks can also be used for reading articles, taking part in courses or workshops, spending time on creative projects, etc. - After the slack, repeat the same cycle until the final product of the project is delivered, and the client is completely satisfied - Slack is not an event and the official Scrum does not mention it

Product Backlog

- Ordered list of all of the requirements. - Items are written in user stories by the product owner in a common language. - Storie, write the goal of the requirement. As a role, I want this function so I get this value. - Stories are asigned story points (tshirt sizing) - Ordered list of everything that might be needed in the final product - All items are described in simple business language - All items estimated in story points - Every requirement and every change in the project will be reflected in the Product Backlog - Dynamically changing and improving - Team does not wait until the Product Backlog is complete to start delivering the items. We only need the first part based on our capacity for the next sprint. - First Sprint can be started as soon as the Product Backlog has a sufficient number of stories - Product Owner sets a number of factors to determine the value of each item for the business - Return on investment is one of the factors - All factors will be summarized into one value - Product Backlog ordered based on item value - Higher-valued items be delivered sooner by the Development team (eat your dessert first)

Timeline of a scrum project

- Product Backlog - Sprint Planning Meeting - Sprint Backlog - Sprint (4 weeks) - Daily Scrum - Product increment - Finished work

Product Backlog Grooming

- Product Backlog Prioritization - Reviewing and revising Product Backlog items -- Adding detail -- Creating estimates -- Ordering items - Product Owner is responsible for prioritizing - Development Team is responsible for estimating - Main difference between grooming and the five Scrum events: -- Scrum events are time-boxed -- Grooming is an ongoing activity - Grooming should not consumo more than 10 percent of the Development team's time

Stories

- Requirements normally written by the Product Owner and come from customer requirements - In an understandable way that everyone understand it - I want to have this deliverable to deliver this value

Sprint Duration Considerations

- Risk of being disconnected from stakeholders (for long sprints) - Ability to go to market with a product release (The longer your sprint the longer you are able to publish it) - Frequency that team composition can be changed - All sprints should be of same duration - No such thing as Sprint Zero

Caracteristics of a Scrum Project

- Scope isnt clearly defined - Product will emerge in project - Changing requirements - Requirements will emerge over time - Activities are vague - Cost and time estimates are challenging - Processes are iterative - New work is dependent on previous work - Customer satisfaction equates to success - Increments create useable value

Scrum Master and Product Owner

- Scrum Master is a servant leader (help the team and product owner) - Product Owner engages stakeholders (represents the business) - Product Owner must be available to the Development Team: -- Scrum Master can inform the Product Owner's functional manager (First coach Product Owner if he is not following the rules, if that doesn't work, you can escalate, you can do it in the retrospective) -- Scrum Master can address the problem in the Sprint Retrospective

What happens to project management?

- Scrum Master responsibilities are different than traditional PM - PM responsabilities are distributed among the three roles - There is no centralized project management in Scrum

Scrum Utilizations

- Scrum can be used in many disciplines. - Our goal is to create working software not just coding, it's to create value - Research and identify viable markets, technologies, and product capabilities - Develop products and enhancements - Frequently release products and enhancements - Develop and sustain Cloud and operations for product use - Sustain and renew products

Monitoring Project Progress

- See how quickly the team is moving thorugh all of the requirements in the Product Backlog, allows us to do some forecasting - Product Owner responsible to monitor the progress of the project - Should be done at least once per Sprint Reveiw - Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints (Information radiator, in a poster so everyone can see it - Forecasts the completion date of the project - All stakeholders hsould have access to this information

Scrum team characteristics

- Self-organized: Scrum team manages own efforts -- Not managed or directed by others (development team decides who does what) -- Management and specialist efforts are not separated in Scrum (you don't have a project manager, a tester, they are part of the team) - Cross-functional: Scrum team has expertise and competencies (People can step up and do more than one role) -- Get the job done without help from outside the team - If work is too large for current team: -- Remove or change selected items -- Recruit additional Development Team members before the work begins

Definition of Done

- Shared understanding of what it means for a piece of work to be "Done" - Definition of DOne mus be discussed and agreed upon at the beginning of the Project os that future increments would be releasable - Over time, the team will improve their definition of DOne to include more stringent criteria - Multiple Scrum teams on a single project: -- Might not be possible to use the same definition of Done for all teams, because they might be working on items of different natures - Each scrum team will define its own definition of done and delivers it items based on that definition - Integration of definitios of DOne should be capable of creating a proterntially releasable increment at the project level

Scrum ceremonies

- Sprint planning meeting - Daily scrum - Sprint review meeting - Sprint retrospective

Sprint Planning Meeting

- The team has a sense of how much they can do in the next sprint. - Requirements are written as a user story. - The team decides how much can they take on and they assign points to items in the backlog (XL, L, M, S). - For example the team can do 20 requirements per week. - The amount of work will be fed into a sprint (4 weeks)

Utilizing Burn UP Chart

- Track the work that has been completed - As tasks get completed the red area gets bigger and the blue area smaller - As work is done the line moves upward - Provides additional insight into the project status

Purpose of the definition of Done

- What constitutes completion for a user story, for a requirement. - Done: Usable feature of the component - Creates transparency over the work inspected at the Sprint Review - Defines requirements for increment to be releasable - Guides Development Team in forecasting at the Sprint Planning

Product Increment

- What the team has done in 4 weeks - Sprint review: Demonstration of what the team has created

Daily Scrum

-Must be attended by the development team. The scrum master doesn't have to be there. - If the scrum master is there, he coaches the team to make sure that the rules are being followed (What has been done yesterday, what's to be done today, what are the impediments to continue) - Development team holds a daily meeting (normally 15 minutes) to coordinate the work for the next 24 hours

FOUR VALUES OF THE AGILE MANIFESTO

1) Individuals and interactions over processes and tools (It is all about relationships, communication, common goal and understanding) 2) Working software over comprehensive documentation (Value for our customer, business need) (Just sufficient documentation) 3) Customer collaboration over contract negotiation (Agile is more about collaboration, flexible, willing to change) 4) Responding to change over following a plan

Finished Work

The product owner can determine if there is a value to release it now or should we wait

Development team

1- Experts that are responsible for delivering backlog items, and managing their efforts -- Cross-functional: capable of the creation of each Product Backlog item (can do more than one role) -- Self-Organized: find their own way instead of receiving orders (they define who will do what) 2- Whole development team responsible and accountable; no individual owns any task 3- Development Team delivers the final product of the project in step by step increments, as defined in the Product Backlog 4- Works full-time in a single project 5- Development Team members should not change often -- Team member changes should not happen during a Sprint -- There will be a short-term decrease in productivity 6- Scrum is effective when there are 3-9 Development Team members

Scrum Master

1- Fully understand Scrum 2- Coaches the Scrum team to ensure all Scrum processes are implemented (eg. Daily Scrum) 3- Management position, which manages the Scrum process, rather than the Scrum team 4- Servant-leader for the Scrum Team (remove impediments, people have the inf. and resources they need) 5- Leads the organization in its effort to adopt Scrum 6- Removes impediments to the Development Team, facilitates events, and trains and coaches team 7- Helps Product Owner by consulting on finding techniques, communicating information, and facilitating related events 8- Helps those outside the Scrum Team understand the appropriate interactions with the Scrum Team (tell outsiders that they can't talk to the development team but to the Product owner, they act as a shield, a defense) 9- Possible for a single person to be Scrum Master and a team member, although this is not recommended 10- Acts as a shield for the team (we don't want people interrupting the team) 11- Can remove team members that are causing conflicts 12- Keep stakeholders abiding by rules (Stakeholders should know and follow the rules) (Status are only available at the end of the spring) 13- For example, only inspecting an increment at the Sprint Review

Sprint Review Meeting

At the end of the sprint. The team does the demo, not the scrum master. - Timebox: Four hours for a four-week sprint, less for shorter sprints - Attendees: Complete Scrum team and key stakeholders (customers you are creating the project for) - Goal: Demo of project work and assessing feedback (showing what we have done to get feedback, there could be some changes that will go into the product backlog and that the product owner will have to re/prioritize, based on the value it gives. If there is a deffect it also goes back to the product backlog)

Sprint Activities

Getting stuff done. Create value by creating things. - Sprint Planning meetings plan what will go into a Sprint - The Product Owner prioritizes requirements and decides contents of the Sprint Backlog (the team decides their capacity and they pull from the top) - Stories make up Sprint Backlog - Team breakdown stories into tasks - Team takes 30 days or so to deliver an agreed amount of stories - Daily Scrum of 15 minutes for team to collaborate with each other -As we get close to the end of the sprint: -- Sprint review team demonstrates the completed stories to customer in a Sprint Demo -- Scrum Retrospective team reviews Sprint and looks for improvement (lessons learned) -- This is followed by a new Sprint Planning - Scrum Master makes sure the Scrum process is followed entirely and offers coaching - If a change comes in a middle of the sprint, the product owner will put it in the product backlog and it will have to wait until the end of sprint, we don't pause the motion in place. There is only one exception.

SCRUM

It is a project management approach. It is an agile framework. It is the most popular of all the Agile approaches. Not always possible to gather all requirements up front, we dont know every particular step.

Roles

Product owner, they represent the product we are creating Scrum master, the coach to get rid of impediments, that everyone is following the rules Development, the team creating the results

Product Owner

Represent the business, the end user the customer. Intermediary between the customer and the development. Understand what customer wants to interact with the development team. Also known as the Value Optimizer. 1- Role belongs to one person -- Can be a committee, but should be one person representing committee -- Do not need to be developers -- Well-versed in how the business operates 2- One Product owner for entire project 3- One Product Backlog for entire project (even if you have multiple development teams, only one product owner, one product backlog) 4- Product owner is responsable for the Product Backlog -- Ensures each user story is easy to understand -- Communicates with customers to keep the Product Backlog updated -- Measures the performance of the project -- Forecasts completion date and makes this information transparent 5- Team and Product Owner work together> -- Too much work a Sprint -- Product owner can cancel a Sprint, not the Development Team 6- Entire organization must respect the Product Owner decisions 7- No one, even the CEO, should try to override decisions 8- No one should tell the Development Team what item to deliver, except for the Product Owner (we dont take changes in the middle of a sprint, it should go to the Product Backlog) 9- Product Owner might delegate some responsibilities to the Development Team, but stays accountable for them (like writing user stories)

Transparency

Requires a common standard so observers share a common understanding of what is being seen: - Common language shared by all participants - Common definition of "Done" (DoD) (What are we creating based on our product backlog, our sprint backlog and what constitude value) (We put up on the wall the status, a burn down chart, information radiator)

Sprint Retrospective Meeting

Right after the Sprint Review Meeting. Looking to improve into people, product and processes. - Timebox: Three hours for a four-week sprint, less for shorter sprints - Attendees: Complete Scrum team, including all roles, the product owner's attendance is optional - Goal: Brainstorm and agree on what is working and what is not The next iteration starts right after this meeting, the sprint planning meeting.

AGILE

Set of methodologies for projects where all the requirements are known at the beginning. Includes kanban, lean. Knowledge work project (Expect change, invisible work, best suited for software development) (Industrial work requires up-front planning)

Daily Scrum

Stand up meeting - Timebox: Fifteen minutes - Attendees: Complete Scrum team (not necessarily the scum master, or product owner, not for management, customers) Sometimes the Scrum master participates to make sure they answer the three questions, what have I done yesterday, what I'm doing today, what are the impediments to continue) - Goal: Progress and impediments (That we know where we are going, that we are making progress)

Product Roadmap

Visual timeline of major product features to be delivered and is normally created by the Product Owner

Sprint Planning Meeting

You are going to see how much capacity does the team have to take user stories into their sprint (sizing, the goal of the sprint, how much work can we do to accomplish that goal) - Timebox: Eight hours for a four-week sprint, less for shorter sprints - Attendees: Complete Scrum team (scrum master, development team and product owner), including all roles - Goal: Team capacity, Sprint Goal/Definition of Done, Sprint Backlog (we all have to be in agreement going into the spring)