• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Gerrard Consulting Business Story Manager Introduction  v5

Gerrard Consulting Business Story Manager Introduction v5



A webinar introducing the Business Story Manager product available at https://businessstorymanager.com

A webinar introducing the Business Story Manager product available at https://businessstorymanager.com



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Business Story Manager supports teams in structured projects who have a strong focus on requirements and acceptance testing and are accountable to stakeholders.It uses stories, scenarios and examples (described in plain language) to improve the accuracy and completeness of requirements and to provide an assured acceptance process,It’s one implementation of our Story Platform. We have another implementation called Maelscrum which supports Agile projects. Take a look at our Maelscrum.com for more information.
  • Increases the Chance of Delivery SuccessDelivering IT projects is very difficult and most individuals don’t really see the big picture. For as long as anyone can remember, the success rate of IT development projects has been poor. There is a slow but steady improvement, but the experience of most stakeholders is still that systems 'miss the mark' by some margin.Our use of business language throughout requirements, development and testing assures consistency as well as correctness. The requirements knowledge base will be consistent with the delivered system and will significantly increase your chances of delivery success of the initial implementation and subsequent enhancements.
  • Reduces the Cost of Re-WorkDo you know what your current cost of re-work is today? You may be surprised to learn that it’s rarely less than 30% of the overall project cost. The majority of these re-work costs are purely down to inconsistent and incomplete requirements. Capturing, understanding and stabilising the user requirements and delivering against them is a real challenge. Most development projects encounter a mass of rework that cripples development and it’s not unusual for this to account for 50% (or even more) of the system costs.Our use of stories and scenarios to example requirements provides unambiguous models for development. They increase confidence in the validity of requirements by covering them in a systematic way. Omission, inconsistency and ambiguity is much reduced and the amount of costly re-work is greatly reduced too.
  • Increases Confidence in TimelinesJust how confident are you in your own project timescales?Business cases for new systems usually understate the challenge of delivery and delivering on time. Progress in IT projects is often measured using IT-focused metrics that have little meaning to stakeholders. Business projects use business language to define business goals and manage progress and so should IT.The same stories and scenarios used to example requirements can also be used to mark progress, to aid the production of training materials, to identify support requirements and to improve business acceptance. With all disciplines working from a single, accurate source of knowledge, your timelines will be far more predictable.
  • So, with our delivery challenges in mind, lets look at the process.There are so many opportunities for mis-communication, it’s a wonder we ever deliver the required solution.And they are not all purely between the business and IT.Traditionally, requirements have been key and even though our industry has had many years to get this right, we somehow still manage to fail to meet stakeholder expectations, leading to frustration and an increased lack of confidence and trust.Business doesn’t really care what development approach is being used, they just want it to deliver! When suppliers are involved then the communications gaps become even more numerous and hard to manage.And when timescales extend to accommodate changing business needs, communications are even more challenged.
  • All development approaches require a level of formality, the level may vary but discipline is always required in some for or another.And of course there are different “styles” of implementation of structured process.And, even within agile, there are projects that adopt some practices and not others.In our experience, most projects are not at the two ends of the spectrum, but somewhere in between. Stories are not exclusive to agile, they are just as meaningful to structured processes. So, regardless of the development approach, stories are universal as examples of features in use - so they really are meaningful everywhere
  • But what does a story actually look like?Here we’re using a simple book order by way of illustration.Each story has two components.A story header to describe the feature, using the “As a; I want; So That” structure.Plus a number of scenarios to describe examples of that feature in use.We only show one scenario here, but there would be many of these for each header.Each scenario uses the “Given; When; Then” structure which is fast becoming the industry standard for stories.
  • This shows what a story looks like within Business Story Manager.In this instance, using the ATM Application we use for training purposes.Note the colour coding showing business terms and data items. These are used throughout Stories, Requirements and Tests. This is managed via our Dictionary function which I’ll explain on the next slide. To find out more about how to create and use stories, take a look at the tutorials on our website, or request a trial account and check it out.
  • Our Dictionary has three components.The glossary of terms can either be uploaded if you have one, or it can be created within Business Story Manager.Each glossary term can be a Definition, an Abbreviation or an Acronym. There are three different levels of progression for a glossary term created within Business Story Manager, and we use colour coding to identify them; Initially when you propose a term (using square brackets to identify it), the text becomes pink. When the term has a definition assigned, the text becomes orangeAnd when the term has been approved, the text becomes green. When you’re creating story scenarios and test scenarios, you may want to create data items. Essentially this allows you to use the same scenario with different data examples. You can identify a data item using the angled brackets and it will automatically be added into the Data Items section of the Dictionary.The Index is a very powerful function as it shows where all the glossary terms and data items are used throughout all requirements, story scenarios and test scenarios. This not only avoids confusion when setting up the glossary terms (having different terms mean the same thing or the same term meaning different things) but it also supports you with impact analysis when changes come along.
  • Business Story Manager also has a document library.This facility allows you to upload documents and images that you want to refer to within BSM.For example, requirements documentation that you want to refer to when creating stories, or business process diagrams to support you when creating business process paths and test procedures.
  • What comes first, the requirement or the story? Actually, in BSM it doesn’t matter, you have total flexibility to choose how you want to work.It’s traditional to start with requirements – so you can do this and derive your stories from them, using your stories to validate the requirements.However, if you ask a user what they want, they usually tell you a story – so you can capture the story directly, create different scenarios to give specific examples of that feature and then use that to elicit requirements. This can be a very fluid iterative process and can extend over several weeks, in fact in itself, it’s an agile method of working.Once stories and requirements are considered to be complete, they can be fed directly to the developers so that they use the same information as everyone else. As the examples of features in use are in English and therefore easy to understand, there is less opportunity to misunderstand and develop incorrect software. Tests are derived from the same stories and once the software has been developed, more detail can be added into the tests to reflect how that feature has actually been implemented. Stories can also generate test code to support test driven development.These activities map directly back to the Business and IT Domains. Or you could think of them as Customer and Supplier domains. In this situation, you can use the tests created within BSM to supplement your contractual agreement. You will still need to undertake your own acceptance testing, but evidence of development test results will give confidence that starting acceptance testing is worthwhile.
  • In terms of implementation of BSM, there are three key areas within the legacy project life-cycle.Initially, business analysts and/or users use the software to support the analysis phase. BSM generates reports that can be used in prototyping workshops to verify that the requirements are complete and consistent . There are likely to be a few workshop sessions during the analysis phase. Once the trusted requirements and stories are approved, they are used to drive development activity. The same information can be used to support the development of any training material and to assist the support organisation to prepare for implementation of the system. During development, changes can be captured within BSM. The dictionary index identifies all instances of where business terms and data items are used to support impact analysis so that change can be managed more effectively. The business scenarios created during analysis automatically become the test scenarios required for acceptance. The testers will add more definition to the scenarios to reflect the way specific functionality has been implemented, and extend the data items to create the required test data.The test scenarios and test procedures will be used to manage the testing activity, information can be exported into your preferred test management tool.
  • We can help you in two ways.Firstly, we can work alongside you to deploy our Business Story Method. We package training, piloting and coaching activities to get you started. And we can deliver on a fixed price basis so there are no nasty surprises with the cost of implementation. This method delivers three key benefits:Confidence in testing coverage without bureaucratic paper mountainsReduced re-work in development and test effort by eliminating inconsistencies and omissions in requirementsAutomated support for functional and acceptance testingUltimately, it delivers improved quality and trustworthiness of requirementsIn addition, we can set up a Business Story Manager account giving you access to our hosted service. Initially you can have this for a free months trial and once you’re comfortable to use BSM on a project, you can either continue to use the hosted service, or have your own service set up within your organisation. BSM is a purpose built tool that supports our methodology.It provides a repository for requirements, stories, scenarios business processes and test scripts that can be used and re-used within your projects. Most importantly, it’s easy to use and supports the application throughout it’s lifetime. Talk to us about the options and pricing.If you’re using both legacy and agile development methods, you’ll be pleased to know that the BSM licence includes the Maelscrum implementation.
  • In summary, we believe that everything flows from good requirements. Using stories to ensure requirements are complete and consistent along with use of business language throughout the entire life-cycle reduces ambiguity.The less ambiguity the less opportunity for creating unnecessary changes.If you’d like to find out more about BSM, or Maelscrum, please take a look at our “Getting Started” or Tutorial videos on our websites.Or you can request a service briefing workshop which includes a one-month free trial account.
  • Use the Enquiries and Feedback facility on the website, or you can contact me directly on susan@gerrardconsulting.com.

Gerrard Consulting Business Story Manager Introduction  v5 Gerrard Consulting Business Story Manager Introduction v5 Presentation Transcript

  • Business Story Manager Overview
    Slide 1
  • Key Business Challenge 1
    Delivery Success?
    Slide 2
  • Key Business Challenge 2
    Slide 3
    % Cost of Re-Work?
  • Key Business Challenge 3
    Slide 4
    Confident of Timelines?
  • Business Domain
    The Delivery Process
    Business Goals
    Acceptance Tests
    Extended Timeline? - Some re-work inevitable as change is constant
    IT Domain
    A mystery to the Business
    Just deliver the right system on plan!
    Development Process
    hot spots
    Slide 5
    Intelligent Testing, Improvement and Assurance
    © 2010 Gerrard Consulting
  • Stories Bridge Communication Gaps
    Slide 6
    Process Formality
    Most projects fit somewhere in between
    Stories Are Always Meaningful
    • Varying formality, but ALL require discipline
    • Stories are universal as examples of features in use
  • Story Header
    Feature: ship orders
    As a orders clerk
    I want to acknowledge and ship the order
    So thatwe fulfil a book order
    Scenario: ship a single book from stock
    Given I select a valid order
    And the ordered book is in stock
    When I choose ‘acknowledge and ship’
    Then order status is changed to ‘shipped’
    And an address label is printed
    What is a Story?
    Slide 7
  • Business Story Manager Example
    Slide 8
  • The Dictionary
    Slide 9
    Glossary Terms
    The INDEX
  • The Document Library
    Slide 10
  • Slide 11
    Stories and Projects
    Business Domain
    Stories validate
    or elicit
    + Test Detailing
    Stories derived from written requirements can be used to walk-through business scenarios and when users see the proposed system ‘in action', requirements anomalies stand out and trigger informed discussions of situations, variations and outcomes. A disciplined approach to story-writing and…
    Stories derived
    from requirements
    Tests derived
    from stories
    IT Domain
    Stories generate
    test code for TDD
    Stories example
    the rules
    Define rules
    • Developers using TDD can use business stories as a ‘starter for 10’
    • Coverage of Business Stories is a necessary, but not sufficient, contractual requirement
  • Analysis
    Business Story Manager and Projects
    Evolving requirements, incremental story development, requirements testing, fortnightly updates etc.
    Build Stories and Scenarios
    Verify Requirements
    Design, Build System
    Functional System Test
    System Integration
    Non-Functional Testing
    Test Design
    Acceptance Test Prep.
    Project Phases
    BSM Implementation
    Acceptance Test Execution
    Slide 12
  • Scope of GC Services
    Slide 13
  • What Next?
    Slide 14
  • What Next?
    Slide 15