Budget Ids

Budget Ideas (Instructional Design, E-Learning and things I love)

19 11 2013

SCRUM – Crash Course

admin | SCRUM

When you’re trying to keep up, sometimes the best course are those you crash right into. Youtube is a great place to learn when you’re on a budget.

SCRUM (wiki version):

Scrum is an iterative and incremental agile software development framework for managing product development.[1][2] It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”,[3] challenges assumptions of the “traditional, sequential approach”[3] to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.

A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility[4]) and that there will be unpredictable challenges—for which a predictive or planned approach is not suited. As such, Scrum adopts an evidence-based empirical approach—accepting that the problem cannot be fully understood or defined up front, and instead focusing on how to maximize the team’s ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions.

SCRUM is a development methodology. Here is a typical software development life cycle.

Waterfall

Waterfall is probably the most traditional software development methodologies, is completed in this order

 

PROs

  • Discipline through phase progression
  • Simple to implement
  • Easy to manage
  • Perfect when know what it takes to get what you want

CONs

  • Linear (no going back)
  • Phases is owned by different team
  • Little collaboration between teams/phases
  • Plan everything upfront
  • Strict requirements, hard to change scope

Triple Constraints

  • Scope (fixed) > Time (flexible) > Cost (flexible)

usually, 86% of projects are challenged or failed, less than 30% complete and 30% canceled before begin. (Standish Group Survey)

Overview

AGILE

Agile development is an umbrella term for several iterative and incremental software development methodologies. The most popular Extreme Programming (XP), Scrum, Crystal Dynamic Systems Development Method (DSDM), Lean Development and Feature Drive Development (FSS)

Initiation and Planning > Iterations

After a group of IT veterans met, they came up with the Agile Manifesto

The team is cross-functional!

Nine reasons why it works

  1. Customer rep is in the driver seat
  2. Quick reaction to changing market and needs
  3. Visibility
  4. Ideal environment for development
  5. Self-managed teams
  6. Removes confusion and distraction
  7. Plan as you go
  8. Issues are less disruptive
  9. Continuous improvement

Triple constraints now: Cost and Time (fixed) and Scope is flexible

Same survey 805 organization going Agile, US military using Agile since 2012,

SCRUM Iteration

 

 

 

 

 

 

 

 

 

SCRUM Ceremonies (meeting)

 

 

 

 

 

 

 

 

 

 

The Team (workers)

  • Product Owner – Responsible for product
  • Scrum Master – Protects the team
  • Team – (Dev, QA, Bus. Analys) – Does the work
  • 7 +/- 2 people
  • Collocated
  • Completely dedicated to a single product or project
  • Static – minimal to zero variations in team
  • Self-managed
  • Cross functional
  • Do not share resources
  • Chicken / Pig (Pig committed/do work & Chicken involved)

Stakeholders

  • Everyone else

Ceremonies

  • Release planning
    • High level estimated road map
    • Release equals period of time or actually installation, but not a commitment
    • workers / those involved
  • Backlog Grooming/Story Tine
    • Whenever needed, just long enough
    • Glimpse into the future
    • worker (involved by invite)
  • Sprint Planning
    • Start of every sprint
  • Daily Scrum/Stand Up
    • 15 min day
  • Sprint Review /Demo
    • Show team accomplishments
  • Sprint retrospective (Inspect & Adapt)

Artifacts

  • Program backlog – High-level list of work for multiple products
  • Product backlog – Single source of truth for the product
  • Team / Sprint backlog – List of all work for a given sprint
  • Stories – Small, specific unit of work to complete and acceptance criteria
  • Team objectives – Team goals for Sprint, both committed work, and stretch goals
  • Definition of done – Team defined list to complete before something is ‘done’
  • Taskboard – Visual representation of work

Product Backlog

  • Single source of all truth for product
  • Contains all work, if there may get done, not there not going to happen
  • visible to everyone
  • Anyone can add to it
  • Opportunities, not commitments
  • Managed by the Product Owner (PO) and will prioritize the backlog
  • Used for planning and tracking, dynamic and getting refined
  • Items at top are backlog are more than refined than the items at bottom of the backlog
  • Types of items: story, bug, chore, epic and prototype features, theme and spikes
  • Vertical slices of functionality (without layers just ingredients)

User Story 

  • Who is asking
  • End goal
  • Where should I start
  • When will I be done?
  • How does the work change as the subject or user change?
  • How does the work change as the reason change?

As a —–, I want —–, so that I can —–.

  • A good user story Invest (Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable) and 3C’s (Card, Conversation, and Confirmation)
  • Work on all stories include: Analysis/Define, Design, Build, Test and Verify
  • Should be small enough to complete in one or two days

Decompose the story, take something large and break it down as small as possible.

 

 

 

 

 

 

 

 

 

 

Story – Written in voice of user

Technical – Written for technical

Spike – Used for research

 

Theme contains many Features that contain Epic contains Stories contain Task (Size may vary based on perceptions, just because you think it is small enough, it may not be) Need input from one doing work to see how to break down and what it good enough.

Prioritizing 

  • Build the highest value first, on most essential stories first

Sprint Planning

Game Planning

  • Regular, repeatable work cycle
  • Length defined by team/program, sweet spot is 2 weeks
  • Once defined, length should not change
  • Consistent cadence
  • Sprint scope should not change
  • End goal is potentially shippable increment of functionality, not the entire flow
  • 90-120 minutes per sweet (about 4 hours planning)
  • Has what and how
  • For the workers
  • Good ideas to have workers from other teams to discuss dependencies

The What

  • SM facilitates meeting
  • PO presents the next priorities from backlog
  • Team presents technical items the want or need to do during sprint
  • the team discusses and asks the PO questions
  • Team breaks down stories as needed
  • Team estimates each story

The How

  • PO leaves the team
  • SM facilitates the meeting
  • Team calculates sprint capacity
  • Team discusses the stories in more detail, create smaller tasts and sub-tasks as needed
  • Team adds stories to team/sprint backlog
  • Stop when capacity if filled
  • Team confidence vote and commitment
  • Stretch goals

Post-Planning

  • Scrum Master (SM) presents the team commitments to Product Owner (PO)
  • PO may re-prioritize based on commitments
  • If PO requests changes, team repeats part 2
  • If no changes, then team commits to work and should be no more sprint scope adjustments. Tornadoes happen, so adjustments can be made, but only for major disasters

Work is only committed after sprint planning
Everything else is an estimate
No one but the team can commit to the team

Estimate

  • It is relative. Size is relative and scale is understood by everyone.
  • Relative size vs. relative complexity
  • Effort vs Degree of Difficulty
  • Estimates are not given to the team, the team gives the estimates
  • Method is not important
  • Key is that everyone understands the scale

Common method to estimation is Story Points

  • Modified Fibonacci Sequence
  • Planning Poker
  • Finding baseline story
  • Estimate the stories relative to baseline

Capacity Allocation

How much work the team can fit into the sprint

  • Either based on time or estimated based on past performance
  • Influenced by vacation, non-project meetings, external appointments
  • Manage risks and unknowns by NOT filling 100% of capacity

How much of each kind of work can we fit into the sprint (60% new stories, refactoring15%, technical debt, architecture)

  • Can’t postpone new implementation
  • Can’t postpone technical debt (problem in code)
  • Capt postpone support

Definition of Done

  • Team created and accepted criteria
  • Generic enough for nearly all tasks
    • Acceptance criteria attached
    • Coded
    • Peer review and code review complete
    • QA passed
    • PO has revised and accepted
  • Does NOT always mean installation

Principle of Good Enough

  • Perfect is too expensive
  • Quick and simple designs
  • Functional
  • Can be extended
  • Emergent architecture
  • No gold plating (extra effort for little value)

Daily Scrum

  • Same time every day
  • Time box, 15-minutes
  • Standing up at taskboard
  • 3 questions: What did you do yesterday, what will you do today? Any impediments
  • Take note of questions and address afterward
  • For workers

Scrum of Scrums

  • Collaboration and transparency across teams
  • Programs with multiple interdependent teams
  • At least once a week, with 1 rep from each SCRUM team
  • Time limit 15 minute
  • Attendees answer same questions at higher level of detail

Sprint Review

  • End of ever sprint
  • Team presents accomplishments (demo, walk through documentation, findings, etc)
  • POs official seal of approval, because not done until PO says so
  • Other people can ask questions
  • PO should be from customer’s side and approval
  • Gather performance metrics
  • Collect feedback from attendees
  • Celebrate

Retrospective 

  • Kaizen – continuous improvement
  • End of every sprint
  • 45 minutes for every week in sprint
  • 3 questions: What went well? What went wrong? What can we do to improve?
  • Only workers, no steak holders, want this to be transparent, only people on team
  • Team building (play games, appreciate each other, team outing, honest and transparent communication)

Metrics

  • Agile/Scrum = High Transparency
  • Sprints
  • Release period
  • Potentially shippable increments
  • Stories committed
  • Stretch goals
  • Capacity – how much room the team has
  • Velocity – how much work can be done
  • Cadence is important (Planning / Release / Retrospective)
  • Burn down chart
  • Burnup chart
  • Feature Progress Report
  • Predictably Measure

 

Source: https://www.youtube.com/watch?v=wNwfFStmtw8

 

 

 

 

Source: https://www.youtube.com/watch?v=mJRsSbWR3Mc

 

This material is for reference only, not intended for anything other than notes I took from watching videos on Youtube. I found both sources very well put together and extremely informative.

Comments are currently closed.