CEN4010 - Module 3
Throughput
-Through is the measure of the number of items that were delivered in a given time period. -By delivered, we mean that each item "flowed" through our Kanban board. -We usually capture metrics about our throughput in a given interval.
What can we do if we have members in a team who work on items that represent different type of work with different statuses? (choose one)
Use multiple swim lanes on the board for the different types of work.
Weighted Shortest Job First (WSJF)
WSJF = Cost of Delay / Duration Cost of Delay = User-Business Value + Time Criticality + Risk Reduction | Opportunity Enablement Value -When both cost of delay and duration can vary, we can use this formula. -When comparing, the highest WSJF should be done next!
When managing the Inflows of the Portfolio backlog, which of the following is true? (choose one)
We should focus on the opportunities which show overwhelming value relative to its cost.
Kanban as a practice focuses on measuring flow, which means ______ . (choose one)
We want to focus on how well the work is started and finished in our system.
Estimate Stories with relative Story points
-A Story point is a singular number that represents: --Volume: how much is there? --Complexity: how hard is it? --Knowledge: what do we know? --Uncertainty: what's not known? -Story points are relative; they are not connected to any specific unit of measure -Compare with other stories (an 8-point story should take 4X longer than a 2-point story)
The Agile Release Train (ART)
-A virtual organization of 5 - 12 teams (50 - 125+ individuals) that plans, commits, and executes together -Program Increment (PI) is a fixed timebox; default is 10 weeks -Synchronized Iterations and PIs -Aligned to a common mission via a single Program Backlog -Operates under architectural and UX guidance -Frequently produces valuable and evaluable system-level Solutions
Program Increment (PI) Planning
-Before an ART starts the Program Increment, a period of time is dedicated to plan the Program increment. -A special meeting or ceremony with the all the team members, architects and stakeholders occurs to determine which features will be worked on, an this is known as the PI Planning. -Cadence-based PI Planning meetings are the pacemaker of the Agile Enterprise. --Two days every 8 - 12 weeks (10 weeks is typical) --Everyone attends in person if at all possible --Product Management owns Feature priorities --Development teams own Story planning and high-level estimates --Architect/Engineering and UX work as intermediaries for governance, interfaces, and dependencies
Scaled Agile Framework (SAFe) - Core Values
-Built in quality -Program execution -Alignment -Transparency
Envisioning - High-Level Product Backlog Creation
-Create Epics (large user stories) using User Story format: As a____________, I want to ___________ so that ___________. -People who created the product's vision write the Epics with assistance of a ScrumMaster and Dev Team (if possible)
Refine Minimum Releasable Features (MRFS)
-Delivering more features is always riskier than delivering less features. Therefore the product owner should work. -Product owner should work with stakeholders to get a consensus of what will be bring acceptable value to the users during the release. -MRF should be defined independently of the cost,as they should define the features that will meet the users' value threshold for this release. -Determining that MRFs are not economically viable allows us to pivot early.
Grooming the Product Backlog
-During product planning, we often construct a backlog of high-level items (epics) which we identify as a set of minimum releasable features for each release. -At release planning, these epics are too large to work with, therefore... --Items will need to be refined before the release planning meeting. --Items will need to be refined during the release planning meeting. -One way to do this is through a User Story writing workshop. -When the story is small enough, we can have a rough idea of the cost and complexity.
Visioning - Popular Vision Formats
-Elevator Statement -Product Datasheet -Product Vision Box -User Conference Slides -Press Release -Magazine Review
Release Planning
-Even though agile processes produce value every sprint, the decision to release completed functionality needs a plan. -Release planning must balance customer value and overall quality against the constraints of scope, schedule, and budget. -Organization need to determine the proper cadence for releasing features -Some organizations deploy at the end of every sprint while others choose to release a feature as its completed and before the end of the sprint. -Continuous deployment or continuous delivery is the process of deploying as soon as the feature is completed, instead of waiting for an iteration to complete. -Release planning occurs frequently, once during each sprint before Sprint planning. -The purpose of planning is to focus on what should be release for the product by a given timeframe. -Release planning requires the participation of stakeholders and the scrum team.
Two weeks
-Every two weeks, teams evaluate the status of the new, integrated system increment. --Features are functionally complete or "toggled" so as not to disrupt demonstrable functionality --New Features work together, and with existing functionality --Architectural Runway work in process is scaffolded and toggled --System is continually verified via Story and Feature acceptance tests --All practical NFR testing is done continuously -Demonstrate the full Solution increment to stakeholders every Iteration. --An integrated Solution demo --Happens after the teams' demo (may lag by as much as one Iteration, maximum) --Demo from the staging environment, or the nearest proxy
Innovation and Planning Iteration
-Facilitate reliability, Program Increment readiness, planning, and innovation --Innovation:Opportunity for innovation spikes, hackathons, and infrastructure improvements --Planning: Provides for cadence-based planning --Estimating guard band for cadence-based delivery
Release Constraint Scenarios
-Fixed Everything: Not realistic for Scrum, as we know that we don't know everything up front. -Fixed Scope and Date: Usually not possible, as increasing the budget after a project has started is difficult to do. -Fixed Scope: Possible, as we can extend the date if we don't have the scope ready. -Fixed Date: Most likely scenario to work with Scrum. We can release on a given date but the scope and date must be flexible. Identify realistically what MRFs can be delivered by a date, and all others are considered "nice to have".
Portfolio Planning - Participants
-Focus is on both new and in-process products -Includes as appropriate: internal stakeholders, product owners of individual products, senior architects, technical leads -Stakeholders need broad business perspective -Stakeholders typically are organized as an Approval Committee or Governance Board -Product owners participate as champions -Senior architects & Technical leads participate to ensure technical constraints are considered
Fixed Date Planning
-Given a fixed date, we can calculate the number of sprints that a team has before the date. -We can calculate the average velocity times the number of sprints to get the overall velocity that the team has before the fixed date. -From that overall velocity, we should commit 70%-80% of the points to MRF. -Over allocating more velocity can place the team in a difficult spot if: --Urgencies occur that require the team's attention. --Running out of time does not allow use to drop any non-MRF features.
Flow - Inspect and Adapt
-Our mission then must be to Inspect and Adapt. This means we review our existing policies and process and make changes that will reduce lead time and cycle time. -If we shorten the cycle time, we also shorten the lead time. -Minor changes in our policies can have dramatic results in our lead time.
Main Scheduling Strategies - 2. Calculate Cost of Delay
-Goal:Determine financial impact for delaying product(s) in the Portfolio Backlog -One method (Leffingwell) suggests evaluating: User value - potential value in the eyes of the user, Time value - how user value decays over time, Risk reduction/opportunity enablement - the value in terms of mitigating a risk or exploiting an opportunity -Alternative "Calculate Cost of Delay" method utilizes a general profile of the delay cost --Descriptions of Scheduling: ---Linear: A product with a cost of delay that increases at a constant rate. ---Large fixed cost: A product that accrues a one-time cost if not acted on immediately; for example, we received a substantial payment only after the product is delivered. ---Must do now: We experience an immediate and aggressively increasing cost of delay; a product without which we incur immediate lost revenue or cost savings that continue to grow over time. ---Fixed date: A product that must be delivered by a fixed future date and therefore has a zero cost of delay until the fixes date occurs. ---Logarithmic: A product that accrues most of the delay cost very early, with increasingly less incremental delay thereafter. ---Intangible: A product that has no apparent cost of delay for an extended period of time and then suddenly accrues a very high delay cost. (Could be technical debt tipping point)
4. Strategy - Managing In-Process Products
-Guides the organization as to whether it is appropriate to preserve, pivot, deliver, or terminate an in-process product -Decisions usually made at the end of each sprint but occasionally off-cycle times due to abnormal events -Lots of strategies for dealing with in-process products with one being the use of Marginal Economics -Use Marginal Economics --From an economic perspective, all work performed to the decision point is a "sunk cost" (let's not evaluate it based on past investment) Focus is on marginal economics of taking the next step (sprint) --Question: Is spending the next chunk of $ justified by the ROI that would be generated? --Use marginal economics to consider our options: preserve, deliver, pivot, terminate
Communicating progress on the release
-How does the team communicate the progress if they have a fixed-scope? -How can the stakeholder understand how much progress has occurred based the sprint rage which was given by the team? Answer:Burndown / Burnup Charts!
Use Software Development
-In Software development, we visualize a work item as a "card". -These cards represent a piece of work to be done and is placed on a Kanban board. -The card usually contains the following information: --Task name/description --Who it is assigned to --A unique Id --An estimate if applicable --Deadline if any --Other info as desired by the team
Portfolio Planning - Process
-Includes newly envisioned product candidates as well as existing portfolio products -New product data includes: cost (how much?), duration (how long?), value (what does it provide that we don't have), and risk (any uncertainty?) -Existing product data includes: customer feedback, updated cost and schedule and scope estimates, technical debt levels, and market-related data -Outputs include: portfolio backlog of approved and prioritized future products. Set of active products: new and approved products slated for immediate development, current and approved to continue and in-process products
Estimation is a whole team exercise
-Increases accuracy by including all perspectives -Builds understanding -Creates shared commitment -Estimation performed by a manager, architect, or select group negates these benefits
Envisioning - Product Roadmap Definition
-Initial Product Roadmap is based on the product vision (artifacts) -Roadmap consists of a series of releases for achieving some or all of our product vision -Releases are developed in an incremental manner allowing for incremental deployments in some cases -Each release focuses on a "small" set of Minimum Releasable Features(MRFs), also known as Minimum Viable Product (MVP), and Minimum Marketable Features (MMF) -Some organizations prefer a fixed, periodic release of its MRFs -Each release should have a clearly defined Release Goal -High-level architecture and technology issues included -Allow for any significant market events that could influence timing -Consider how far into the future for the roadmap, at least as far as asking funding for
Benefits of Kanban
-Kanban delivers features faster by shortening cycle times. -Kanban is responsive to disruptive changes. -Kanban aims to reduce waste in the system. -Kanban allows stakeholders to visualize the impediments and bottlenecks.
Flow
-Kanban focus on flow. So in theory, work started is not valuable unless its finished. -Therefore Kanban emphasizes finishing work over start new work. -This is why if we reach a WIP limit, team members should not focus on pulling new work but finishing the existing work. -Part of establishing Kanban means the team will have to "Map the workflow" so for each work item to be considered finished it will have to travel through this workflow. -To map the flow, we need to know: --Where do tasks come from? --How are they prioritized and assigned? --What are the steps or states that an item will go through to be considered done? -Analysis -> Design -> Develop -> Test -> Release?
Envisioning - Timing
-Never-ending, so long as there are product visions or products to maintain -Idea passes through a Strategic filter -Define the minimal first release -Eventually actionable feedback informs a product's future
Align to a mission with PI Objectives
-Objectives are business summaries of what each team intends to deliver in the upcoming PI. --They often map directly to the features in the backlog ... But not always. --For example: ---Aggregation of a set of features, stated in more concise terms ---A milestone like a trade show ---An Enabler Feature needed to support the implementation ---A major refactoring -Features are decomposed into Stories by the teams on the train. -The Team Backlog organizes the team's work --It represents opportunities, not commitments—a list of what we want to do --Items may be estimated (preferable), but estimates do not imply committed delivery --It has a single owner: the team's Product Owner, who is also part of a larger PO/PM team --It is largely driven by Program priorities -The Backlog contains User Stories --User Stories replace traditional requirements, and describe intended system behavior.
Variable Quality
-Often there is another variable that suffers when scope, date and budget are fixed...the quality of the product. -Quality is what customers would care mostly about and should not be sacrificed. -If Quality is sacrificed, technical debt will be accrued which must be paid back in the future. -Test engineers should be responsible for preserving quality and should be vocal when this is not the case.
SAFe Levels
-Portfolio --Where Epic owners manage the value streams with Kanban. A value stream represents a set of Epics that bring value to customers and can be mapped to one program. -Value Stream --A Single Value Stream that can be implemented by multiple Agile Release Trains (Optional level) and is funded by different budgets. -Program --The level where the team of teams resides (Agile Release Train). The teams demo their features in a system demo on a cadence known as the program increment. -Team --Where an Individual Scrum team lives and works on features which are prioritized at the program level. The team operates in sprints and demos.
Portfolio Planning - Timing
-Portfolio Planning takes the envisioning of a product and determines whether to fund the product and how to sequence it into the Portfolio Backlog -Never-ending, so long as there are products to develop or maintain
PI Planning Input: Prioritized Features
-Prioritizing is done with WSJF (Weight Shortest Job First) -In order to calculate WSJF, teams need to estimate Cost of Delay and duration -For duration, use job size as a quick proxy for duration -Relative estimating is a quick technique to estimate job size and relative value -WSJF stakeholders: Business Owners, Product Managers, Product Owners, System Architects
Envisioning - Participants
-Product Owner is the only required participant but others can participate: --Stakeholders --Specialists (such as Market Research, Business-case Development, User-Experience Designers, Systems Architects) --ScrumMaster & Dev Team -Reenvisioning during Scrum involves the entire Scrum Team
Scaled Agile Framework (SAFe)
-Scaled Agile is a methodology which aims to synchronize the development of features across a large organization. -SAFe has evolved as a proven approach for developing complex systems and software in a Lean-Agile manner and draws from three primary bodies of knowledge: Agile development, systems thinking, and Lean product development -Framework scales to accommodate organizations with thousands of people. -Some large adopters may have as many 400 teams and 40-50 trains. -The Framework creates good code/components quality, which is important, because "You can't scale crappy code." -Lean is extremely keen on trust and transparency. The framework depends on transparency. Lean won't work if organization hides behind it's politics. -SAFe embraces the concept of an Agile Release Train (ART). -The Agile Release Train is a synchronize team of teams concept, in which the teams operate with scrum to deliver features that are the most important to stakeholders across an organization. -An ART is viewed as a "long-lived team of teams". -All of the teams in the ART operation in a synchronized fashion. The teams on the ART work on prioritized features by the stakeholders.
The Agile Release Train (ART) - Roles
-Scrum Master --Runs team meetings, drives agile behavior --Removes impediments; protects the team from outside influence --Attends Scrum of Scrum meetings -Product Owner --Defines and accepts storeis --Acts as the customer for developer questions --Works with product management to plan PIs -Agile Team --Create and refine user stories and acceptance criteria --Define/Build/Test/Deliver stories --Develop and commit to Team PI Objectives and iteration plans OTHER ROLES -Release Train Engineer acts as the Chief Scrum Master for the train -Product Management owns, defines, and prioritizes the Program Backlog -System Architect/Engineering provides architectural guidance and technical enablement to the teams on the train. -The System Team provides processes and tools to integrate and evaluate assets early and often. -Business Owners are the key stakeholders on the Agile Release Train
Envisioning - Process
-Simultaneously considers the Inputs -Involves several different activities -Generates important Outputs
Swim Lanes
-Swim lanes are horizontal lanes typically used in Kanban when items flow through different paths. -For example, have multiple teams working out the same board but the work items will flow through different paths with different columns (states)
Envisioning - Other Activities
-Target Confidence Threshold may require other activities: --Minimal Market Research into target customers --Minimal Competitive Analysis --Minimal Business Model -May organize envisioning work into one or more sprints --May involve knowledge-acquisition work such as prototype or proof of concept -Economically Sensible Envisioning --Synonyms: project chartering, inception, or initiation -Target a Realistic Confidence Threshold -Focus on Short Horizon -Act Quickly -Pay for Validated Learning -Use Incremental/Provisional Funding -Learn Fast and Pivot (aka Fail Fast)
Cumulative Flow Diagram
-The CFD is an area graph which shows the work flowing through the system in a given state. -It shows how much work is in the system, when it arrives and when it departs.
Flow - Lead Time, Cycle Time
-The Lead Time measures from when the work item was created (in this case by the customer) until it is delivered to whom created it. --Since the ticket was placed on May 3rd and released on May 7th, the lead time is 5 days! -The Cycle Time measures from when the work item was started to when the work item was delivered. --Since the work was started on May 5th and released on May 7th, the cycle time is 3 days! -So, Lead Time = 5 days, Cycle Time = 3 days.
Kanban Board - Software development
-The card usually resides on a Kanban board, which contain the different "states" the work item has to travel through to be considered done. -Also, the board will have a state to denote the Ready phase and a state to denote "Done" -The development team should be concerned with moving backlog items from the "ready" column to the "done" column. -All work being done by the team should be a card on the board. Remember it is important to visualize the work. -Each column in the Kanban board needs to establish a WIP limit. A WIP limit is an aggreged upon number of work that the team can handle for that state. -If the WIP limit is reached in a column (indicates a bottleneck), no more work should be pulled until a card is moved from that column. -If the WIP limit must be broken for an urgent item, the team should still focus on resolving the bottleneck immediately.
Release Constraints
-The goal of release planning is to determine what constitutes the most valuable next release and what the desired level of quality is. -The constraints of scope, date, and budget are important variables that affect how we will achieve our goal.
Enabler Stories support value
-They can represent different types of work: --Exploration --Architecture --Infrastructure
When managing outflows in portfolio planning, which is NOT considered a good strategy?
Focus on idle workers, not idle work.
Principles of Kanban
-Visualize your work: Kanban typically uses boards which allow you to move items from one state to another. This allows you to see your work changing from one state to another, and if there is a bottleneck, this easily visible. -Limit your Work in Process (WIP):Kanban asks you to define what is the maximum work that the team can be engaged in without losing efficiency and asks the team to make sure no more work is being done once this limit it met. -Measure Flow: Since the work is always being visualized, we focus on the "flow" of items in our system from start to finish. Improving the flow means that we improve on our delivery. -Make process policies explicit:As a team identifies opportunities to improve itself, this knowledge is introduced into the -Kanban board. For example, we can reestablish of WIP limit if our current value is not working. -Use Models to recognize opportunities:Understand the models of theory of constraints and waster and flow.
WIP Limits
-WIP Limits are established so that the team does not pull in more work into the system. -Kanban dictates that you shouldn't not pull any more work into the In-Progress column until can resolve the items that are in the column. Why? -If we established the WIP Limit of 3, it's because we determined that to be our capacity to work efficiently. Therefore have more than 3 items will cause a bottleneck for the entire board! -What should we do? We should not pull in any more work until we address the bottleneck. -It's a good practice for the team members to focus on the area that has hit the WIP limit, so that more work can be pulled in. -So if a resource on the team is available, they should not pull in new work, they should help to complete one of the items in-progress.
Sprint Mapping (PBI Slotting)
-We can do mapping (slotting) of near-team product backlog items into the sprint. -The team must be involved. -To do the mapping, we need an appropriately detailed, estimated and prioritized product backlog. -Using a team's velocity, we can map a set of product backlog items for each sprint whose combined size roughly equals the team's average velocity (orless). -If multiple teams are involved, teams can map 2-3 sprints ahead to give visibility to inter-team dependencies.
Kanban
-While Scrum is great tool for working with complex projects, it doesn't have a strict method to deal with change requests. -Kanban is tool for managing the flow of items through a system. -It is a very visual system which allows its participants to visualize the flow of work. -Often uses a Kanban board with different columns to represent the state of a work items (Cards) and swim lanes to show the "flow" lanes.
Portfolio Planning
-an activity for determining which portfolio backlog items: to work on, which order, and for how long -Portfolio Backlog item can be: product, product increment, or project
The Need for a portfolio
-need a way to make economically sound choices for how to manage their produt portfolios
Envisioning (Product Planning)
-the activity of creating product backlog artifacts -Goal of envisioning is to: --Describe the essence of the potential product --Create rough plan for its creation --Be prepared to subject the idea to Portfolio Planning activity -Envisioning is not the same as heavier-weight, ceremonial, plan-intensive project chartering -Scrum principles support the belief that we can't (or should not try to) know all the details about a product before we start
2. Strategy - Managing Inflows - Main Inflow strategies include
1. Applying an Economic Filter for go/no-go decisions -Good filter should quickly show overwhelming value relative to its cost, thus approval 2. Balancing the rate of product insertion (Arrival) into the Portfolio Backlog against the rate of product pull out (Departure) -Goal: Steady stream of arrival and departure products 3. How to quickly embrace an Emergent Opportunity 4. Preventing Portfolio bottlenecks by using smaller, more frequent releases
3. Strategy - Managing Outflows - Main Outflow strategies include
1. Focus on idle work, not idle workers -Principle states that idle work is far more wasteful and economically damaging than idle workers -Ensure a good flow of work on the new product -Ensure the new product will not disrupt the flow of other in-process products 2. Establish a work-in-process (WIP) limit -Goal:Never pull more products out of the Portfolio Backlog than we have capacity to complete 3. Wait for a complete team -Goal: Unit of capacity in Scrum is the team -Incomplete Scrum team is insufficient for getting features to a done state
Main Scheduling Strategies
1. Optimize for Lifecycle Profits 2. Calculate Cost of Delay 3. Estimate for Accuracy, not Precision due to limited data
Four Categories of Strategies (Activities)
1. Scheduling 2. Managing inflows 3. Managing outflows 4. Managing in-process products 1. Scheduling strategies help determine the proper sequence of the products in the portfolio backlog. 2. Inflow strategies guide participants in knowing when to insert items into the portfolio backlog. 3. Outflow strategies inform participants about when to pull a product out of the portfolio backlog. 4. In- process strategy is used to decide when to preserve, pivot, deliver or terminate a product that is currently in process.
Main Scheduling Strategies - 3. Estimate for Accuracy, not Precision due to limited data
Goal: Range values are usually sufficient to determine value
To calculate the Weighted Shortest Job First (WSJF) we need to know the duration and the ________ (choose one)
Cost of Delay
Communicating
Fixed Scope Release Burndown Chart: Shows the total amount of unfinished work that remains each sprint. Fixed Scope Release Burnup Chart: Shows the total amount of work in a release as a goal or target line and the progress in each sprint toward that goal. This chart can also show a change in scope if the target line moves up.
Communicating Progress on a Fixed-Date
Fixed-date-release-burnup chart: A burnup chart with an inverted product backlog (lower priority items are now found higher up in the backlog). When a sprint is completed we update the line to indicate where we are in the release plan.
The measure from when work was requested to when work was delivered is known as the ____. (choose one)
Lead time
Once we reach a WIP limit for a given state, this means that ______ . (choose one)
This identifies a potential bottleneck to the flow and the team should focus on completing the tasks
The measure of how many items flow through the board and are completed is known as the ____. (choose one)
Throughput
Fixed Scope Release Planning: When?
To answer the question of when we will get the fixed set of features, we sum the sizes of all of those features and then divide by our team's higher and lower velocities. The result is a range of sprints within which delivery will take place. Let's say we want 150 story points of features in the next release. If we divide 150 by 18 (our team's slower velocity) and round up, we get nine sprints. If we divide 150 by 22 (our team's faster velocity) and round up, we get seven sprints.
