• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Business Analysis

Agile Business Analysis



This is the slide deck delivered at the Agile Business Conference in London on 6th October 2010

This is the slide deck delivered at the Agile Business Conference in London on 6th October 2010



Total Views
Views on SlideShare
Embed Views



12 Embeds 2,126

http://www.agiledesign.co.uk 2094
https://www.linkedin.com 10
http://www.linkedin.com 6
http://translate.googleusercontent.com 4
url_unknown 2
http://absavocet.co.uk 2
http://ranksit.com 2
http://agiledesign.none65.netdna-cdn.com 2
http://web.archive.org 1 1
http://www.netvibes.com 1
http://prlog.ru 1



Upload Details

Uploaded via as Apple Keynote

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
  • Good afternoon <br /> <br /> Intro - who am I? <br /> <br /> Who is in the room? <br /> <br />
  • These are the key areas we will consider <br />
  • <br />
  • Avoid zombie projects <br />
  • 1 Well lets put this into practice a little. <br /> <br /> 2 In a second I will ask you at your own tables to come up with your own vision, but first lets look at an example <br /> <br /> 3 Imagine I am a traditional book shop looking to develop an online store <br /> <br /> 4 Well we need to come up with a vision statement for our idea <br />
  • COMBINE THIS WITH PREVIOUS SLIDE - USE the vision statement to make sure you are staying on the rails. <br /> <br /> For [target market]&#xA0; who&#xA0; [state need] <br /> the [product name]&#xA0; is a [product category] <br /> that [summarise feature set] <br /> unlike it&#x2019;s competitors&#xA0; [list competitors] <br /> our product will [state differentiator] <br />
  • Exercise <br />
  • 5 - Now it&#x2019;s time for you guys to get your thinking caps on. Lets.come up with a business idea <br /> - Identified an opportunity <br />
  • COMBINE THIS WITH PREVIOUS SLIDE - USE the vision statement to make sure you are staying on the rails. <br />
  • <br /> 1 Prove that ROI is higher than banking the money &#x2013; interest in account is the discount rate. Value of just having cash <br /> <br /> 2 Not going to tell you how to do a business case &#x2013; approach differs from org to org <br />
  • 1 Open conversation about competing project drivers. This is analysis trying to understand what the business care about (e.g. total cost of ownership vs feature set <br /> <br /> 2 The message to come across is &#x201C;what do you actually care about&#x201D; <br /> <br /> 3 Sliders - Rob Thomsett - Radical project managment <br /> <br /> 4 Discuss slide <br />
  • We often also use the notions of drivers and CSFs to determine why a project may be run. <br /> <br /> A project may be considered with respect to departmental / organisational targets <br />
  • 5 Well now you guys have a business case and vision lets build on that and have a conversation about priorities <br /> <br /> 6 What are the success criteria for this project? Is there any factors that will determine whether or not this project will be a success &#x2013; outside sliders &#x2013; e.g extensibility or key dates <br /> <br /> Exercise: Discuss sliders for your project, pros & cons. The message to come across is what do you actually care about <br /> <br /> Against lines : <br /> Maintainability <br /> Performance <br /> Budget <br /> Schedule <br /> Usability <br /> Scope <br />
  • 1 Ok, so we have our vision and we have done enough work on a business case to think that this is at least worth looking at in a bit more detail. So, what else might we think about as analysts. <br /> <br /> 2 Well we now need to elaborate a little on our vision to produce high level requirements <br /> <br /> 3 What do we mean by high level? <br /> - Well not too many details initially, <br /> - more considered view than the vision. <br /> - Skim across the top of the project scope to survey landscape to make sure we undersand the architecture otherwise you drive yourself into a corner <br /> <br /> <br /> 4 Consider things like this: <br /> - What space does the product / project exist in? Business/existing tech/process or greenfield. <br /> - Who cares? (stakeholders / sponsor / users ...) <br /> - How might the need be satisfied &#x2013; may not need to use tech. May need simple/more complex &#x2013; bronze/silver/gold <br />
  • <br /> 1 All of these things matter but, lets first consider who cares about this piece of work <br /> <br /> <br /> 2 Who are your stakeholders? <br /> <br /> What role do they play on your project? <br /> How do they like to communicate? <br /> What about time commitment? <br /> Other rules of engagement? E.g. how do they like to receive info. May depend on bandwidth. May depend on interest &#x2013; chat once a week or daily <br /> <br /> 3 Examples: <br /> Permission giver &#x2013; audit/funding <br /> Interested party &#x2013; marketing <br /> Knowledge source &#x2013; marketing/business/ba <br /> Operations is a good example &#x2013; he needs to be involved as he will not take the project live without maintainability/supportability <br /> <br /> <br /> 4 Who do you know that is not in the room that may be able to give us really important information &#x2013; identifying stakeholders <br />
  • <br />
  • 1 Consider all people and other systems that will interface with your system <br /> <br /> 2 Consider people who play multiple roles. On eBay you act as a Buyer and a Seller <br /> <br /> 3 Consider people who care about your system but will never use it e.g. regulators, architects <br />
  • 1 So lets build on the knowledge that we have so far and discuss the likely stakeholders of your system <br /> <br /> - Consider QA groups - is there anything that can be done in development that would make QA easier? <br /> <br /> - Deployment/maintenance groups &#x2013; stakeholders &#x2013; may also be permission giver &#x2013; will not accept <br />
  • <br /> 1 Ok, well now that we have identified some actors and probably roles another useful tool is called personas. <br /> <br /> 2 ref: Jeff Paton - Pragmatic Personas &#x2013; roles are abstract, personas are concrete examples of users. They are characatyres <br /> <br /> 3 This will help us understand likely useage patterns and will probably drive out the design for the presentation of system to the users. <br /> <br /> 4 It will also start to identify a few more priorities and including target market. If 80% of the usage is likely to come from the hard core gambler then do you even bother with the one off bets. <br /> <br /> 5 May make use of real person examples. Jim in accounts &#x2013; Personas are charactertures <br /> <br /> 6 Market segmentation for dummies &#x2013; personas &#x2013; Market segments are groups of potential buyers who have similar wants, needs, experiences, or problems. <br />
  • Clara <br /> <br /> 25, Computer programmer, pdf, work related titles <br />
  • Steve <br /> <br /> Student, second hand books <br />
  • About - age / demographic / likes / dislikes <br /> Context - where / when / why <br /> Implications - so what <br /> Exercise <br />
  • <br /> When talking about table stakes we might have common table stakes across personnas and common differenetiators. Facebook is a table stake for teenagers on phones but a differentiators for soccer mon. <br /> <br /> Within your systeem what you are actually doing is identifying your target market and within that market what you are doing is identifying the priorities of the feature that those individuals need. <br />
  • <br />
  • 1 Lets have a look at how we might partition the features of the bookstore to identify a roadmap that delivers value to our customers <br /> <br /> 2. Describe the roadmap for the bookstore. Computing titles only - business decision, reduce necessary contracts etc. sufficient for first launch. <br /> <br /> 3 Consider MMF 1, can we split? is browse only of value? Do we need online payments? <br />
  • 1 Now it&#x2019;s your turn again&#x2026;So, lets have a quick talk about MMFs in your product and see if we can identify some. <br /> <br /> 2 Challenge yourselves about the minimal nature of the MMFs &#x2013; take out one or two bullet points and ask yourself if it&#x2019;s still marketable. <br /> <br /> 3 Who will see the benefit from this and do you think they will really care about this feature <br /> <br /> 4 What is the value &#x2013; revenue, market leader, cost saver <br />
  • 1 We think we understand the marketable increments for the software and have been given the funding for some initial work so we need a bit more detail about what we will build to satisfy user needs <br /> <br /> 2 What we will discuss in this part of the talk is how and when to capture that detail. <br /> <br /> 3 And during this activity it&#x2019;s important to remember and involve stakeholders. Not just direct users. There will be some negotiation of scope with various stakeholders along the way so your role as a BA shifts to being a facilitator and communicator amongst the different interested parties including the team. You may need to decide on audit trails, architectural concerns, compliance, risk mitigation, project management, purse string holders (scope, schedule, resource) ? <br />
  • Break down into stories <br /> Consider cost options <br /> - bronze / silver / gold <br /> - dirt road vs. asphalt <br /> Select highest value story <br /> - Value to who? <br /> - Risk, communication, knowledge, feedback ... <br />
  • 1 Before we dive into story definition we probably need to just expand on the MMFs a little. <br /> <br /> 2 This will help identify a few user stories naturally as we do the breakdown. <br /> <br /> 3 Take care to ensure that the MMF is as small as it can be. <br /> - Ensure that user stories do not polish one area while neglecting another. <br /> -Example, Don&#x2019;t do CRUD for the titles if create and read is good enough for now to give your customers a list and the go on to make searching easier. <br /> <br /> 4 Helps to do prioritisation &#x2013; maybe delete can wait. <br /> <br /> 5 Depending on the size of the MMF it may be necessary to break down first into epics then to stories. <br /> <br /> 6 Bullets in example are user stories <br />
  • 1 What we should have now is enough information on the MMFs to start elaborating on some user stories. <br /> <br /> 2 I am going to talk about 3 stages that a user story goes through when elaborating the detail - CCC <br />
  • 1 So, here is an example of a user story for our book store. <br /> <br /> 2. Describe As a&#x2026; <br /> <br /> 3. Describe GWT <br /> <br /> 4. Highlight another scenario : What if it does exist? Formatting and validation rules for fields? <br />
  • 1 So lets try to understand what a user story is and what they are for. <br /> <br /> - We use stories to schedule work, sized for the teams convenience. <br /> - A user story starts life as a short statement about a feature that could be added to the product. Mention role, feature, goal <br /> - Sometimes the back of the card will say how we plan to demonstrate the feature <br /> <br /> 2 This highlights one of the greatest strength of user stories. Communication. Nobody can build, test or deploy anything based on a sentence. We need detail. <br />
  • Up front vs. Just in time <br />
  • Confirmation <br /> 1 Here we also discuss the tests that are required to demonstrate correct implementation. This of course has to involve the testing team as what we are doing is defining the acceptance criteria for the story <br /> <br /> 2 Explain GWT scenarios. Given a certain set of conditions when I do something then take this action <br /> <br /> 3 How much detail do we need to be &#x201C;ready for development&#x201D;. Ask yourself if the story satisfied all of the acceptance criteria would that be good enough for production? <br />
  • So, lets have a go at coming up with one or two user stories from the MMFs you have defined <br /> You probably already have a bullet list of candidate user stories to get you going. <br /> Talk through slide and set them off <br />
  • 1 Ok well just as an overview of what we have talked about today: <br /> <br /> 2 Well hopefully we have got you to think about the granularity we are working at. <br /> - Vision may not be revisted that often. <br /> - Mostly focus on feasibility. Made funding decision. <br /> - Working in marketable increments. <br /> - Scheduling work using user stories and collaborating over acceptance criteria so that we can iterate effectively over specification development <br /> - We can see from the slide that most activities are continually in progress in every area. We are not doing waterfall anymore. <br /> <br /> <br /> 3 The role of a BA in the various stages of development of a product in an Agile environment is varied <br /> <br /> 4 They are central to a successful agile implementation producing just enough of the detail at the right time <br /> <br /> 5 At the same time they act as enablers getting the teams to work more effectively together (dev, test, ba, pm, deployment&#x2026;) by being great facilitators. <br />
  • <br />
  • Any questions? <br />

Agile Business Analysis Agile Business Analysis Presentation Transcript

  • Agile Business Analysis David Draper
  • BUSINESS ANALYSIS ACTIVITIES Product Visioning Business Need Impacted Parties User types Incremental Delivery
  • Visioning What is this thing?
  • BUSINESS CASE // VISION Why might we run this project? Revenue generation Revenue protection Cost saving
  • Bookworm Online Bookstore : Vision Convenience for consumers Wide range – everything ‘under one roof’ Ease of browsing / finding Competitive pricing Against conventional book stores Low site operational cost 5
  • Bookworm Vision Statement For customers who would like a more convenient method to purchase books the Bookworm is an online book shop that has an extensive searchable catalogue of books available for purchase unlike old fashioned high street book shops our product will provide a 24x7 service including online payments which means guaranteed faster deliveries. 6 6
  • Vision statement template For [target market] who [state need] the [product name] is a [product category] that [summarise feature set] unlike it’s competitors [list competitors] our product will [state differentiator]
  • Bookworm: Priorities - Competing Project Drivers Maintainability Performance Budget Schedule Usability Scope
  • OTHER CONSIDERATIONS Drivers Critical success factors
  • High level requirements How can these be agile?
  • Who are your stakeholders? Sponsors CIO / COO ... Governance FSA / SOX / Security / PCI / Data protection ... Internal Operations / Software maintenance / development etc.
  • Actors Stake-holders System under design
  • UNDERSTAND YOUR USERS Personas Concrete examples Differentiate user needs Identify usage patterns Identify priorities Identify your market
  • Bookworm: Personas
  • Bookworm: Personas
  • USER TYPES // USER ROLES QUANTITY DEMOGRAPHICS KNOWLEDGE HOW / WHY DIFFERENCES THAT MAKE A DIFFERENCE Jeff Patton - http://www.infoq.com/presentations/pragmatic- personas
  • MINIMUM MARKETABLE FEATURE “... a chunk of functionality that delivers a subset of the customer’s requirements, and that is capable of returning value to the customer when released as an independent entity.”
  • Bookworm : Roadmap - MMF 1: Enter the Market - Offer computing titles only - Browse, select, add to basket - Simple search - Paypal payment - Increase customer base - MMF 2: All categories of books - MMF 3: Multiple payment options - Customer loyalty - MMF 4: Vouchers - MMF 5: Premier members get free delivery - MMF 6: Integrate with warehousing systems 22
  • Bookworm : MMF 1 Enter the Market - Computing titles - CRUD for book details - Author, Title, Cover image, Blurb, Price - Authentication of administrators - Batch upload from stock control system - Simple search - Search by ISBN, Title, Author - Paypal payment - Add / remove items from cart - Persist cart - Log in, log out 26
  • Bookworm : First user story - In order to make books available for purchase - As a book shop owner - I would like to add a new book to the system - Scenarios - Given the book titled “XP explained” does not exist - When I fill in the add new book web form - Then the book will appear in the stock list 32
  • CARD // SPECIFYING THE STORY What is it for and what does it look like? As a ___ I would like ____ so that ____ In order to ___ as a ___ I would like ___ - Scenarios - Constraints / NFRs - Examples - Limitations
  • CONVERSATION // DISCOVER THE REQUIREMENT Communication is key Requirements up front = no challenge Story = Lightweight placeholder for a conversation BA is a facilitator Discover the real requirement
  • CONFIRMATION // ACCEPTANCE CRITERIA Given a certain set of conditions when I do something then take this action Examples: Customer Quantity in Discount Item Price Discount Line Total Basket awarded Code £10.00 3 A 10% £27.00 £5 1 C 0% £5 £20 50 B 15% £850 £1 1 C 5% £0.95 How much detail do we need?
  • Conclusions Breadth first, then depth This is the same approach required for UX and Architecture. Develop details just in time Recognise cost options Understand the value being delivered and to who
  • http://www.valtech.co.uk http://blog.valtech.co.uk http://twitter.com/valtech david.draper@valtech.co.uk http://twitter.com/david_draper http://agiledesign.co.uk