Agile Business Analysis

Editor's Notes

• #2: Good afternoon Intro - who am I? Who is in the room?
• #3: These are the key areas we will consider
• #5: Avoid zombie projects
• #6: 1 Well lets put this into practice a little. 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 3 Imagine I am a traditional book shop looking to develop an online store 4 Well we need to come up with a vision statement for our idea
• #7: COMBINE THIS WITH PREVIOUS SLIDE - USE the vision statement to make sure you are staying on the rails. 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]
• #8: Exercise
• #9: 5 - Now it’s time for you guys to get your thinking caps on. Lets.come up with a business idea - Identified an opportunity
• #10: COMBINE THIS WITH PREVIOUS SLIDE - USE the vision statement to make sure you are staying on the rails.
• #11: 1 Prove that ROI is higher than banking the money – interest in account is the discount rate. Value of just having cash 2 Not going to tell you how to do a business case – approach differs from org to org
• #12: 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 2 The message to come across is “what do you actually care about” 3 Sliders - Rob Thomsett - Radical project managment 4 Discuss slide
• #13: We often also use the notions of drivers and CSFs to determine why a project may be run. A project may be considered with respect to departmental / organisational targets
• #14: 5 Well now you guys have a business case and vision lets build on that and have a conversation about priorities 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 – outside sliders – e.g extensibility or key dates Exercise: Discuss sliders for your project, pros & cons. The message to come across is what do you actually care about Against lines : Maintainability Performance Budget Schedule Usability Scope
• #15: 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. 2 Well we now need to elaborate a little on our vision to produce high level requirements 3 What do we mean by high level? - Well not too many details initially, - more considered view than the vision. - 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 4 Consider things like this: - What space does the product / project exist in? Business/existing tech/process or greenfield. - Who cares? (stakeholders / sponsor / users ...) - How might the need be satisfied – may not need to use tech. May need simple/more complex – bronze/silver/gold
• #16: 1 All of these things matter but, lets first consider who cares about this piece of work 2 Who are your stakeholders? What role do they play on your project? How do they like to communicate? What about time commitment? Other rules of engagement? E.g. how do they like to receive info. May depend on bandwidth. May depend on interest – chat once a week or daily 3 Examples: Permission giver – audit/funding Interested party – marketing Knowledge source – marketing/business/ba Operations is a good example – he needs to be involved as he will not take the project live without maintainability/supportability 4 Who do you know that is not in the room that may be able to give us really important information – identifying stakeholders
• #18: 1 Consider all people and other systems that will interface with your system 2 Consider people who play multiple roles. On eBay you act as a Buyer and a Seller 3 Consider people who care about your system but will never use it e.g. regulators, architects
• #19: 1 So lets build on the knowledge that we have so far and discuss the likely stakeholders of your system - Consider QA groups - is there anything that can be done in development that would make QA easier? - Deployment/maintenance groups – stakeholders – may also be permission giver – will not accept
• #20: 1 Ok, well now that we have identified some actors and probably roles another useful tool is called personas. 2 ref: Jeff Paton - Pragmatic Personas – roles are abstract, personas are concrete examples of users. They are characatyres 3 This will help us understand likely useage patterns and will probably drive out the design for the presentation of system to the users. 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. 5 May make use of real person examples. Jim in accounts – Personas are charactertures 6 Market segmentation for dummies – personas – Market segments are groups of potential buyers who have similar wants, needs, experiences, or problems.
• #21: Clara 25, Computer programmer, pdf, work related titles
• #22: Steve Student, second hand books
• #23: About - age / demographic / likes / dislikes Context - where / when / why Implications - so what Exercise
• #24: 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. 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.
• #26: 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 2. Describe the roadmap for the bookstore. Computing titles only - business decision, reduce necessary contracts etc. sufficient for first launch. 3 Consider MMF 1, can we split? is browse only of value? Do we need online payments?
• #27: 1 Now it’s your turn again…So, lets have a quick talk about MMFs in your product and see if we can identify some. 2 Challenge yourselves about the minimal nature of the MMFs – take out one or two bullet points and ask yourself if it’s still marketable. 3 Who will see the benefit from this and do you think they will really care about this feature 4 What is the value – revenue, market leader, cost saver
• #28: 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 2 What we will discuss in this part of the talk is how and when to capture that detail. 3 And during this activity it’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) ?
• #29: Break down into stories Consider cost options - bronze / silver / gold - dirt road vs. asphalt Select highest value story - Value to who? - Risk, communication, knowledge, feedback ...
• #30: 1 Before we dive into story definition we probably need to just expand on the MMFs a little. 2 This will help identify a few user stories naturally as we do the breakdown. 3 Take care to ensure that the MMF is as small as it can be. - Ensure that user stories do not polish one area while neglecting another. -Example, Don’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. 4 Helps to do prioritisation – maybe delete can wait. 5 Depending on the size of the MMF it may be necessary to break down first into epics then to stories. 6 Bullets in example are user stories
• #31: 1 What we should have now is enough information on the MMFs to start elaborating on some user stories. 2 I am going to talk about 3 stages that a user story goes through when elaborating the detail - CCC
• #32: 1 So, here is an example of a user story for our book store. 2. Describe As a… 3. Describe GWT 4. Highlight another scenario : What if it does exist? Formatting and validation rules for fields?
• #33: 1 So lets try to understand what a user story is and what they are for. - We use stories to schedule work, sized for the teams convenience. - A user story starts life as a short statement about a feature that could be added to the product. Mention role, feature, goal - Sometimes the back of the card will say how we plan to demonstrate the feature 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.
• #34: Up front vs. Just in time
• #35: Confirmation 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 2 Explain GWT scenarios. Given a certain set of conditions when I do something then take this action 3 How much detail do we need to be “ready for development”. Ask yourself if the story satisfied all of the acceptance criteria would that be good enough for production?
• #36: So, lets have a go at coming up with one or two user stories from the MMFs you have defined You probably already have a bullet list of candidate user stories to get you going. Talk through slide and set them off
• #37: 1 Ok well just as an overview of what we have talked about today: 2 Well hopefully we have got you to think about the granularity we are working at. - Vision may not be revisted that often. - Mostly focus on feasibility. Made funding decision. - Working in marketable increments. - Scheduling work using user stories and collaborating over acceptance criteria so that we can iterate effectively over specification development - We can see from the slide that most activities are continually in progress in every area. We are not doing waterfall anymore. 3 The role of a BA in the various stages of development of a product in an Agile environment is varied 4 They are central to a successful agile implementation producing just enough of the detail at the right time 5 At the same time they act as enablers getting the teams to work more effectively together (dev, test, ba, pm, deployment…) by being great facilitators.
• #39: Any questions?