Scribd Logo
Upload

Welcome to Scribd!

  • 130 views

    Agile Ba Cheat Sheet: Second Edition

    Uploaded by

    Lee Spadini

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Agile Ba Cheat Sheet: Second Edition

    Uploaded by

    Lee Spadini
    130 views1 page

    Original Title

    Agile_BA_Cheat_Sheet_2nd_Edition_2018

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    130 views1 page

    Agile Ba Cheat Sheet: Second Edition

    Uploaded by

    Lee Spadini

    Copyright:

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

    AGILE BA CHEAT SHEET

    UK.LINKEDIN.COM/IN/SOLUTIONEER


    @IANCARROLLUK

    SECOND EDITION
    0844 357 1024
    The aim of this cheat sheet is to provide Agile Business Analysts with a quick reference
    card that may help them with their day to day work. For further details on Agile [email protected]
    requirements management visit out website.
    WWW.SOLUTIONEERS.CO.UK

    DEMAND NEXT ANALYSIS DEV TEST SHOWCA


    WIP DONE WIP DONE WIP DONE WIP SE
    RECOMMENDED READING

    2 3 4 5
    1

    STRUCTURE OF AN INCEPTION

    RELEASE PLANNING
    1) It’s your job as BA to work closely with the Product Owner 2) The NEXT column is used to drive out priorities and identify
    to constantly groom the demand coming into the team. the next work item for the team to start next. Make sure you
    Look for work that keeps getting trumped by other work to only pull from this column WHEN YOU HAVE THE CAPACITY TO
    see if it’s genuinely needed. The correct level of story detail DEAL WITH IT. If you pull too much work in, then you will just
    at this stage could be as little as the title of the story written become a bottleneck and create a bigger hand-off with
    on the card. Getting into too much detail at this point risks the rest of the team. It’s easy to fall into the trap of thinking
    waste as you may not have access to Dev’s and Tester’s or you’re helping the team go faster by getting ahead with
    the story may get trumped by other work. Remember, the story writing but you are in fact slowing the team down. You
    longer the period of time between a story being written and want to do just enough up front work to allow you to focus
    a developer picking it up degrades quality and requires a more on fleshing out the story detail (if needed) closely WITH
    greater effort of hand over. This is why we never hand-over a developers and testers. If you hit your WIP limits go
    story but instead write stories with Dev’s and Tester’s. downstream to help out in Dev & Test (see point 4&5 below).
    Remember the golden rule: Always look downstream for
    more work before pulling work from the left.

    3) STORY WRITING Non-Functional Requirements (NFR’s)


    Writing stories is a group activity with Product Owner, UX,
    Don’t forget your NFR’s! Run workshops to understand, REQUIREMENTS HIERARCHY
    Accessibility, Availability, Compliance, Efficiency,
    Developers, and Testers. You can use a number of formats
    Extensibility, Interoperability, Maintainability, Performance,
    to articulate your requirements:
    Privacy, Quality, Resilience, Response Time, Scalability,
    Security, Testability, Usability…
    • As a (user role), I want (goal), so that (benefit)
    Minimal Viable Product (MVP) - the minimal amount of
    • <action> <result> <object>
    functionality that can be produced to test an idea or a
    • As <who> <when> <where>, I <what> because <why>.
    hypothesis. This does not represent the full go to market
    product. It is used to validate assumptions quickly.
    Articulating Acceptance Criteria (from BDD):
    Minimal Marketable Product (MMP) – the minimal amount
    of functionality that can be produced to take a product to
    • Given <scenario>, when <action>, then <result>
    market.
    Story Sizing
    Other artefacts that teams often include in their stories are
    • Never, ever, size in hours, days, or any unit of time.
    wireframes, graphical assets, test data packages,
    • The purpose of sizing is to validate if you’ve broken
    technical diagrams. Basically, include anything that helps
    down your stories enough
    teams to gain a common understanding of what is
    • Use relative T-Shirt sizing – S, M, L, XL. Start by finding the
    required.
    biggest story and put that in XL. Then find the smallest
    and put that in S. Now simply offset the remaining CYNEFIN
    What’s the correct level of detail?
    stories. Break down L’s or XL’s. Repeat.
    It depends! Use the Cynefin model to assess what level of
    Story Splitting
    detail is needed. For example, if the requirement is Simple
    • Workflow steps
    or Obvious then maybe a simple descriptive title on a card
    is enough. Complicated stories may need more detail such
    • Business Rule Variations COMPLEX COMPLICATED
    • Major Effort Unknown Unknowns Known Unknowns
    as using the story formats above but with more prescriptive
    • Simple / Complex Probe-sense-respond Sense-analyse-respond
    supporting artefacts such as wireframes or data. For
    • Variations in Data
    Complex stories, don’t constrain the team but simply write
    • Data Entry Methods
    the problem statement using one of the formats above
    • Defer Performance
    and let them explore options and solutions with you.
    • Operations (e.g. CRUD)
    • Breakout a spike
    For large projects or pieces of work, run an inception to de-
    Look at your acceptance criteria - each acceptance
    risk and understand key areas such as Biz Case, Customer
    criteria often represents a split! CHAOTIC SIMPLE OR OBVIOUS
    Journey, and Technical Architecture.
    Unknowable Unknowns Known Knowns
    Act-sense-respond Sense-categorise-respond
    4) It’s really critical that you work closely with Developers. A 5) It’s very common in an Agile software development
    tight feedback loop is required. Work on building strong team for Business Analysts to ‘swarm’ downstream to help
    relationships with all developers. You should be regularly out in Test. As with pairing up with Developers, you can do
    pairing up with Developers to answer any queries or clarify the same with Testers. A clear understanding of how the
    any requirements. Encourage Developers to regularly software is tested is critical and a key area for Business
    showcase their work to you and constantly listen out for Analysts to work with Testers to feed into the Test Strategy.
    conversations between developers that you can contribute You may also be called upon to actually do some hands-on
    constructively to. testing. Keep yourself close to how the software is evolving.
    Copyright © 2018

    You might also like