Scribd Logo
Upload

Welcome to Scribd!

  • 10 views

    Twenty Ways To Split

    Uploaded by

    Francesco Paraggio
    The document lists 20 ways that stories for a software project can be split or divided up, such as by implementation approach (manual vs automated), architecture (single user vs multi user), user interface (character vs GUI), functionality (main flows vs alternative flows), scope (one feature vs many features), testing priorities (base case vs general case), and quality attributes (low fidelity vs high fidelity). Splitting stories in these different dimensions provides flexibility in how a project can be planned and developed.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content

    You might also like

    Twenty Ways To Split

    Uploaded by

    Francesco Paraggio
    10 views1 page
    The document lists 20 ways that stories for a software project can be split or divided up, such as by implementation approach (manual vs automated), architecture (single user vs multi user), user interface (character vs GUI), functionality (main flows vs alternative flows), scope (one feature vs many features), testing priorities (base case vs general case), and quality attributes (low fidelity vs high fidelity). Splitting stories in these different dimensions provides flexibility in how a project can be planned and developed.

    Original Description:

    Twenty Ways to Split

    Original Title

    Twenty Ways to Split

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    The document lists 20 ways that stories for a software project can be split or divided up, such as by implementation approach (manual vs automated), architecture (single user vs multi user), user interface (character vs GUI), functionality (main flows vs alternative flows), scope (one feature vs many features), testing priorities (base case vs general case), and quality attributes (low fidelity vs high fidelity). Splitting stories in these different dimensions provides flexibility in how a project can be planned and developed.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    Download as pdf or txt
    10 views1 page

    Twenty Ways To Split

    Uploaded by

    Francesco Paraggio
    The document lists 20 ways that stories for a software project can be split or divided up, such as by implementation approach (manual vs automated), architecture (single user vs multi user), user interface (character vs GUI), functionality (main flows vs alternative flows), scope (one feature vs many features), testing priorities (base case vs general case), and quality attributes (low fidelity vs high fidelity). Splitting stories in these different dimensions provides flexibility in how a project can be planned and developed.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    Download as pdf or txt
    of 1

    Twenty Ways to Split Stories

    The Big Picture


    Research

    Implement

    What have others done?

    Spike

    Implement

    Explore a quick solution

    Manual

    Automated

    Often have to retain manual solution anyway

    Buy

    Build

    Can go either way; trade cost of customizing

    Build

    Buy

    Single-User

    Multi-User

    Fewer worries about scale, user accounts

    API only

    User Interface

    Tests may function without user interfaces

    ..versus cost of implementing yourself

    Character or Script UI GUI

    Simple interface can prove out ideas

    Generic UI

    Custom UI

    Naked Objects approach can be cheaper

    Static

    Dynamic

    Do once and ignore updates

    Ignore Errors

    Handle Errors

    Minimize error code (dont ignore exceptions)

    Transient

    Persistent

    Focus on behavior over persistence

    Low Fidelity

    High Fidelity

    Quality of result (e.g., pixel depth)

    Unreliable

    Reliable

    Perfect uptime is very expensive.Wm. Pietri

    Small Scale

    Large Scale

    Build load capacity over time

    Less ilities

    More ilities

    Address non-functional requirements later

    Few Features

    Many Features

    Easier to do fewer features

    Main Flow

    Alternative Flows Happy path vs. all possible paths

    Nothing is easier than something

    Many

    One is easier than a bunch

    One Level

    All Levels

    One level is the base case for all levels

    Base Case

    General Case

    Base case must be done; others neednt

    Ilities

    Features

    See full article, Twenty Ways to Split Stories, http://xp123.com/xplor/xp0512


    Copyright 2009, William C. Wake, xp123.com

    You might also like