Scribd Logo
Upload

Welcome to Scribd!

  • 1K views

    Agile One Pager PDF

    Uploaded by

    Egeruoh Chigoziri Cyrinus
    for scrum masters

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd

    Agile One Pager PDF

    Uploaded by

    Egeruoh Chigoziri Cyrinus
    1K views2 pages
    for scrum masters

    Original Title

    Agile one pager.pdf

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    for scrum masters

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    1K views2 pages

    Agile One Pager PDF

    Uploaded by

    Egeruoh Chigoziri Cyrinus
    for scrum masters

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 2

    Agile One Pager

    Principle behind the Agile Manifesto


    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    Kanban / Lean
    Visualization of top priority items Pull system of work assignment

    Scrum
    Value based prioritization Shippable SW after each Sprint Sprint Review Product Backlog grooming Re-prioritization after each sprint

    XP
    Customers and Developers work together to plan releases

    DSDM
    Build customer feedback into each iteration to converge on an effective business solution MoSCoW

    Crystal
    Early Victory Walking skeleton Frequent Customer feedback

    FDD
    Client-Value based features Short ramp-up for modeling

    Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

    Business people can change and re-prioritize work not yet started at any time

    Iteration planning

    Re-calibration of the release plan Frequent User feedback

    Domain based model fosters change Short cycles with complete features allow for frequent change Increments (per feature) <= 2 weeks Iterations (1 or more complete features Client interaction during processes #1 and #2 Frequent demos with customer feedback Domain Experts Class ownership However, there is Team leadership Assignment of team membership based on expertise Multiple Small teams Joint design, inspections etc. However, a lot of information sharing via CMS

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

    Work released on demand

    Sprints (iterations)

    Iterations

    Develop iteratively in Timeboxes

    Iterations

    Highly collaborative

    PO as VOC PO readily available to team on a daily base

    Customer is part of the Team

    Involve the right stakeholders, at the right time, throughout the project

    Easy access to expert users Frequent feedback from end users Process Miniature makes sure team members understand the process well Team decides improvement / changes

    SM is only facilitator Self-organizing teams Demo/Acceptance after each sprint

    Open work space Pairs evolve as needed

    The most efficient and effective method of conveying information to and within a Development Team is face-to-face conversation.

    Co-located teams Daily Stand-Ups

    Co-located teams Daily Stand-Ups

    Co-located teams Daily Stand-Ups

    Co-located teams for Crystal Clear Osmotic Communication Daily Stand-Ups

    2012 SCRUMstudy.com

    Agile One Pager

    Principle behind the Agile Manifesto


    Working software is the primary measure of progress.

    Kanban / Lean
    WIP limit

    Scrum
    Working SW at the end of each Sprint

    XP
    No technical debt TDD Egoless software Iteration planning Sustainable, predictable pace

    DSDM
    Deliver Good enough early instead of Perfect too late

    Crystal
    Walking Skeleton Automated Tests Frequent Integration -Blitz planning

    FDD
    Inspections (Unit) tests

    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    No fix release or delivery dates Limit of WIP forces completion or work packages

    Velocity Done criteria (Only complete/done work counts)

    Clearly defined entry/criteria per process only completed work counts

    Continuous attention to technical excellence and good design enhances agility.

    Refactoring

    Continuous Integration, refactoring & building often

    Incremental Rearchitecture

    Domain Object Model as base Frequent updates

    Simplicity--the art of maximizing the amount of work not done--is essential.

    Small user stories Continuous reevaluation and reprioritization

    Small user stories Continuous reevaluation and reprioritization

    Small features Focus on Client value Good upfront design / model

    The best architectures, requirements, and designs emerge from self-organizing teams.

    No team leader Team commits Team member select tasks

    Pair Programming Team coding standards

    Members of the team empowered to make decisions on behalf of those they represent without waiting for higher-level approval.

    Side by side programming

    Team consensus for Domain Object Model Small teams foster cooperation across expertise boundaries

    At regular intervals, the team reflects on how to become more effective, and then tunes and adjusts its behaviour accordingly.

    Retrospective Meetings at the end of each sprint

    Retrospective meetings at each iteration end. Improving the process is part of the development.

    Facilitated workshops

    Reflection Workshop

    The 6 milestones per feature allow for frequent checks for improvements However, no reflections are prescribed

    2012 SCRUMstudy.com

    You might also like