sepC

• Sprint Planning
• Sprint Review
• Sprint Retrospective
• Daily Scrum

• Team selects items from the product backlog they can commit to completing
• Sprint backlog is created
  • Tasks are identified and each is estimated (1-16 hours)
  • Collaboratively, not done alone by the Scrum Master
• High-level design is considered

• Parameters
  • Daily
  • 15-minutes
  • Stand-up
• Not for problem solving

• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying architecture
• Informal
  • 2-hour prep time rule
  • No slides
• Whole team participates
• Invite the world
• Onle “Done’s” are presented 

• Periodically take a look at what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
  • Scrum Master
  • Product owner
  • Team
  • Possibly customers and others
• For example
  • “Start / Stop / Continue”
  • “Good / Could be better/ Measures” 

• Product Vision
• Sprint Goal
• Product Backlog
• Sprint Backlog
• Definition of Done
• Burn-Down Chart
• Increment
• Burn-Down Chart

Traditionally for smaller projects due to planning uncertainties.

Great for big projects or projects, that are low risk. There's lots of overhead in smaller projects though.

Requirements are changed as necessary. Begin Development as soon as possible (when MVP-Requirements are available)

Define requirements in the beginning and after verification, built the entire system.

Define process / measures for Change Management in order to change the requirements. Generally less open to change.

Only plan 1 sprint / iteration at the time. See which tasks get completed and then continue.

Plan every milestone in advance. Attempt to never change the planning again.

A good user story should be:

• “I” ndependent (of all others)
• “N” egotiable (not a specific contract for features)
• “V” aluable (or vertical)
• “E” stimable (to a good approximation)
• “S” mall (so as to fit within an iteration)
• “T” estable (in principle, even if there isn’t a test for it yet)

A software process model is an approach to the development of software and determines how the project is to be carried out. (phases, activities, roles, methods, tools and documentation)

• Basis for the software project management
• Management: Planning-and control-oriented

A process is the actual execution of sets of (ordered) activities in a projectToday a process model includes looping back to inspect & adapt.

It moves downwards in the project definition phase (Verification)

At the bottom, there's the implementation / coding phase (validation)

After the implemtation, it moves up again with various validation phases (which are corresponding to the phases on the same horizonal level of the project definition phase)

There was a frustation that the traditional models couldn't adapt with the need of fast paced development and changing requirements. Old models caused too much overhead and bureaucracy.

Due to the fast evolvement of the personal computer and the whole industry, developer needed a more flexible approach to get rapid feedback of the endusers.

1. Start where you are
   1. Kanban provides the flexibility to be overlaid on existing structures, without disrupting them. Make changes and extensions as you go.
2. Agree to Pursue Incremental, Evolutionary Change
   1. Kanban encourages continuous small incremental and evolutionary changes to the current process. Don't make sweeping (big) changes, as they usually encounter resistance.
3. Respect the Current Process, Roles & Responsibilities
   1. Kanban recognizes that existing processes, roles, responsibilities, and titles have value and are, generally, worth preserving.
4. Encourage Acts of Leadership at All Levels
   1. This is the newest Kanban principle. It reminds you that some of the best leadership comes from everyday acts of people on the front line of their teams. It is important that everyone fosters a mindset of continuous improvement (Kaizen) in order to reach optimal performance on a team/department/company level. This can’t be a management level activity.

1. Visualize the workflow
   1. The first and most important thing for you is to understand what it takes to get an item from request to a deliverable product.
2. Limit work in progress
   1.  a primary function of Kanban is to ensure a manageable number of active items in progress at any one time.
   2. Limiting WIP means that a pull system is implemented on parts or all of the workflow.
3. Manage Flow
   1. By flow, we mean the movement of work items through the production process.
   2. Ideally, we want fast and smooth flow. This would mean that our system is creating value quickly. This way we can minimize the average cycle time for production and avoiding the cost of delay but in a predictable fashion.
4. Make Process Policies Explicit
   1. You can’t improve something you don’t understand. This is why the process should be clearly defined, published and socialized.
5. Feedback Loops
   1. In order for the positive change to happen, succeed and continue, one more thing needs to be done.
   2. Such are the daily stand up meetings for team synchronization.
   3. There are also the service delivery review, the operations review, and the risk review meeting.
6. Improve Collaboratively (using models & the scientific method)
   1. Shared vision
   2. shared understanding of theories about work, workflow, process, and risk

• CFD (cumulative flow diagrams)
  • to visualize work "in progress"
• Run Chart
• Lead Time Distribution Chart
• Failure Load and Blocker

In a stable System:

\(Lead Time = \frac{WIP}{Throughput}\)

Hence:

• Maximize Throughput: Reduce WIP
• Minimize Leadtime: Reduce WIP

Scaling Agile Framework

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

• Satisfy customer through early delivery
• Welcome changing requirements
• Deliver frequently
• Business people and developers work together
• Motivated individuals...
• Face-to-face conversation
• Working software
• Sustainable development
• Attention to technical excellence
• Simplicity
• Self-organizing teams
• Regular self-reflection

• To plan
• To schedule (f.e. releases)
• Plan ressources (or hire them if needed)
• Price and guide investment

It's a method for estimating story points. The SM sits together with the development team:

1. SM picks a task and reads it to the development team
2. Each teammember picks one of his planning poker cards which states "how big" the tasks is in his/her opinion.
3. The cards are shown (turned public) all at once.
4. If the whole team agrees good. If the estimate vary heavily, the "player" with the highest amount and one with the lowest one justify their picks (on why this tasks takes that long)
5. The estimates are continued until theres consens.

A list of all User Stories and Tasks that the team wants to complete in the current sprint.

The team is responsible for it.

A relative work estimate to other User Stories.

Fibonacci Numbers are used because large numbers reflect the uncertainty, for which the team estimated certain User Stories.

1. Scrum
2. XP
3. DevOps

• Waterfall
• V-Model
• RUP

Kanban is a Pull-System

Steps of the process pull work that has been completed in the prior step to their "group", rather than the issue being pushed into the next step upon completion.

Lead time is the time it takes from an issue appearing till its completion / delivery to the customer.

It's a metric which shows how efficient your timeline is. If the lead time is too high, it means that there are to many issues being worked on and they're not completed. Fix it with a WIP Limit, by increasing capacity or efficency or stop taking new issues.

It's the time a tasked is actually processed. From In Progress to Done

It's lmiting on how much tasks is being worked on simultaniously.

Throughput per Unit of time is the average of item produced in a given time period.

Can be compared to velocity (Scrum)

• Transparency is important and useful
• Can manage the workflow better
• Kanban optimizes the workflow
• Happier Staff

How quickly a team is achieving the User Stories

Viewed as how much more is left to complete over time within a Sprint iteration

How quickly a team is achieving the User Stories

Viewed as how much has been done over time within a Sprint iteration

The number of story points a team can complete during / or has completed in the past of an iteration

Enables the team during Sprint Planning to determine how much they can commit to, based on past iterations.

Remarks:

• Don’t use the metrics to blame any team!
• Can’t compare Velocity of Team A : B!