Agile Business Analysis
by david_draper on Oct 07, 2010
- 1,134 views
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
Accessibility
Categories
Tags
Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 1
- Downloads
- 18
- Comments
- 0
- Embed Views
- Views on SlideShare
- 543
- Total Views
- 1,134
Intro - who am I?
Who is in the room?
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
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]
- Identified an opportunity
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
2 The message to come across is “what do you actually care about”
3 Sliders - Rob Thomsett - Radical project managment
4 Discuss slide
A project may be considered with respect to departmental / organisational targets
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
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
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
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
- 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
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.
25, Computer programmer, pdf, work related titles
Student, second hand books
Context - where / when / why
Implications - so what
Exercise
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.
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?
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
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) ?
Consider cost options
- bronze / silver / gold
- dirt road vs. asphalt
Select highest value story
- Value to who?
- Risk, communication, knowledge, feedback ...
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
2 I am going to talk about 3 stages that a user story goes through when elaborating the detail - CCC
2. Describe As a…
3. Describe GWT
4. Highlight another scenario : What if it does exist? Formatting and validation rules for fields?
- 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.
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?
You probably already have a bullet list of candidate user stories to get you going.
Talk through slide and set them off
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.