1 of 26
Slide Notes
As first presented at Productcamp Berlin 2013
sponsors
idealo
location: ImmobilienScout24
Catering : Zalando
T-Shirt Sponsor: Leanovate
Party Sponsor: SponsorPay
Camp Sponsor: Product Owner Dojo / proProduktmanagement / KaufDA / 1&1
This presentation is essentially in two parts
All about the problems I have identified as being pain points for Product Owners and Business Analysts, and finally some techniques that you can use solo, or with your teams, or with your BAs to help boost productivity.
sponsors
idealo
location: ImmobilienScout24
Catering : Zalando
T-Shirt Sponsor: Leanovate
Party Sponsor: SponsorPay
Camp Sponsor: Product Owner Dojo / proProduktmanagement / KaufDA / 1&1
This presentation is essentially in two parts
All about the problems I have identified as being pain points for Product Owners and Business Analysts, and finally some techniques that you can use solo, or with your teams, or with your BAs to help boost productivity.
Unchaining The Analysts: Making BDUF Agile Friendly
Published on Nov 18, 2015
Project managers, product owners and most people who are NOT developers struggle with defining a heavily technical solution... And business analysts of the traditional nature have this technical nous, but struggle to make the transition to using agile frameworks because of the lingering hangover of BDUF/BRUF. If your product owner is out of their depth in a technical sense, then the whole project/area of development and system architecture is placed greatly at risk from creeping bugs, unknown dependencies, and missing stories. Simply adding a BA to your team will likely create more problems than solutions without re-engineering the need to know all the facts into something that fits "just enough and Just in time".
But it doesn't have to be this way.
In this case study based presentation I explore exact the exact methods we used to upskill a Business analyst or requirements engineer, and massage their skillset into a key role that can insure that quality, detail rich stories go into any agile process, while bridging the communication gap and bringing a wealth of "Big Picture" thinking to the bite sized chunks of Scrum development.
MORE DECKS TO EXPLORE
PRESENTATION OUTLINE
unchaining the ANALYSTS:
making bduf scrum friendly
As first presented at Productcamp Berlin 2013
sponsors
idealo
location: ImmobilienScout24
Catering : Zalando
T-Shirt Sponsor: Leanovate
Party Sponsor: SponsorPay
Camp Sponsor: Product Owner Dojo / proProduktmanagement / KaufDA / 1&1
This presentation is essentially in two parts
All about the problems I have identified as being pain points for Product Owners and Business Analysts, and finally some techniques that you can use solo, or with your teams, or with your BAs to help boost productivity.
sponsors
idealo
location: ImmobilienScout24
Catering : Zalando
T-Shirt Sponsor: Leanovate
Party Sponsor: SponsorPay
Camp Sponsor: Product Owner Dojo / proProduktmanagement / KaufDA / 1&1
This presentation is essentially in two parts
All about the problems I have identified as being pain points for Product Owners and Business Analysts, and finally some techniques that you can use solo, or with your teams, or with your BAs to help boost productivity.
Photo by WadeB
@miss__haley
My name is Amber, and I'm about 34% MIscellaneous stuff like cooking and reading,
32% Internet nerd - I love web technologies and new services. I specialise in UX thinking and UI/Interaction design..
But most of all I am an Agilist.
Trained CSP, i work as a Scrum master and Agile coach, and have also been Product side with Scrum as a PO.
Find me on twitter posting random things of interest..
32% Internet nerd - I love web technologies and new services. I specialise in UX thinking and UI/Interaction design..
But most of all I am an Agilist.
Trained CSP, i work as a Scrum master and Agile coach, and have also been Product side with Scrum as a PO.
Find me on twitter posting random things of interest..
PROBLEM:
PRODUCT OWNERS AND MANAGERS STRUGGLE WITH TECHNICAL STORIES
The big key word here is domain knowledge.
I often hear PO saying the following: "my teams have to write the stories"
Or
"this work is too technical for me"
Often the technical environment is far more complicated than first realised.
How to cope with the interdependencies of highly technical or back end stories?
Couple this with time constraints and managing stakeholders; actually making your dreams reality gets blocked and stifled.
I often hear PO saying the following: "my teams have to write the stories"
Or
"this work is too technical for me"
Often the technical environment is far more complicated than first realised.
How to cope with the interdependencies of highly technical or back end stories?
Couple this with time constraints and managing stakeholders; actually making your dreams reality gets blocked and stifled.
Photo by Giovanni Toso
IMPACTS
- Poorly defined stories
- Poorly thought out dependencies on technical systems
- Lack of understanding about how stories fit together
- Inefficiencies further along the production line
- Greater number of unknowns on start
- BUGS BUGS BUGS
Also: low moral in team
The potential for a reduction in quality or more bugs OR that you're constantly firefighting.
It all boils down to waste: in time, team focus etc.
The biggest indicator is velocity: check to see if its changing constantly, or staying static instead of improving.
However by far the worst impact is that POs can start to feel less empowered about their products: it's not theirs any more. It becomes a collection of technical tasks.
The potential for a reduction in quality or more bugs OR that you're constantly firefighting.
It all boils down to waste: in time, team focus etc.
The biggest indicator is velocity: check to see if its changing constantly, or staying static instead of improving.
However by far the worst impact is that POs can start to feel less empowered about their products: it's not theirs any more. It becomes a collection of technical tasks.
Photo by x-ray delta one
INTRODUCING THE BACKLOG OWNER!!
SO HOW COULD A B.A HELP?
This roll was first introduced by an Agilist Shanan Holm, and refined in later role iteration By Mike Lowery agile coach.
Find Shanan on twitter @shanan
Find Mike's excellent blog posts on https://nomad8.com
This was initially a way to cope with scrum web development that had a waterfall PM over the top, and later a PO with huge time constraints.
Find Shanan on twitter @shanan
Find Mike's excellent blog posts on https://nomad8.com
This was initially a way to cope with scrum web development that had a waterfall PM over the top, and later a PO with huge time constraints.
Photo by Nina Matthews Photography
RESPONSIBILITIES
- Care for the backlog
- Writing stories in tandem with the PO
- Being the technical interface between the team and the PO
- Championing the product business view
- Adding detail of domains, data interactions, system dependencies.
This is a way to leverage the strength of a BA.
They are accustomed to speaking and uncovering hidden requirements. They have one foot in Analysis and one in solution
So what this role does is channel smaller bite sized chunks of the traditional BA into quality stories that have depth and detail.
They are accustomed to speaking and uncovering hidden requirements. They have one foot in Analysis and one in solution
So what this role does is channel smaller bite sized chunks of the traditional BA into quality stories that have depth and detail.
Photo by o.tacke
ADDS FOCUS
- Removes detail oriented information gathering away from the team
- Works as a permanent PO buddy
- Runs the estimation and grooming sessions
- Owns ensuring the PO's are priorities are reflected in the backlog
- Responsible for training material and sessions.
The intention here is not to replace a PO but to understand the strengths and weaknesses on both sides.
A backlog owner cannot make business weighted decisions about priority, unless empowered to.
They also do not have the power to stop or change sprints.
These decision points are always resting with the Product Owner.
A backlog owner cannot make business weighted decisions about priority, unless empowered to.
They also do not have the power to stop or change sprints.
These decision points are always resting with the Product Owner.
Photo by minifig
PROBLEM:
MOVING PAST BIG DESIGN AND BIG REQUIREMENTS UP FRONT
Predictive thinking can really mess everything up.
Photo by gadl
MOVING PAST BDUF:THE CHALLENGES
- Understanding the concept of "Just enough, Just in time"
- Unknowns are actually ok!
- Writing user stories without getting technical
- Letting go of the how, focusing on the what
- Domain knowledge for the other software sopecific skills e.g. UX, UI design
Like any big change it will take patience and hand holding.
It will take the SM and the PO colab on Story writing coaching and estimation games, and expectation setting.
But i have seen Traditional BA with 25 years indentured in the same job embrace this change and totally rock it.
The point is: none of these hurdles are insurmountable.
It will take the SM and the PO colab on Story writing coaching and estimation games, and expectation setting.
But i have seen Traditional BA with 25 years indentured in the same job embrace this change and totally rock it.
The point is: none of these hurdles are insurmountable.
Photo by Claremont Colleges Digital Library
SOUNDS GREAT!
ERM... HOW DO WE DO THIS?
start small.
start by making the BA your PO shadow.
compare notes after meetings
the main thing that will get this rolling faster is communicating your intention, and acting with trust.
make sure you have your handoff points sorted, what escalation actions need to be in place, who is in charge of what type of communications
then comes the hard part: let go.
start by making the BA your PO shadow.
compare notes after meetings
the main thing that will get this rolling faster is communicating your intention, and acting with trust.
make sure you have your handoff points sorted, what escalation actions need to be in place, who is in charge of what type of communications
then comes the hard part: let go.
Photo by CarbonNYC
WE HAVE NO BA!
BUT... BUT!
Ok so maybe you're a small startup... or you are a large company with no BAs embedded.
This is a hurdle no doubt but there are still methods you can adopt to help nurture whole system and lean thinking.
Start by doing simple flow charts of your audiences moving through the feature you want to develop: these user action maps will at least provide a path for deeper questions into back end touch points.
This is a hurdle no doubt but there are still methods you can adopt to help nurture whole system and lean thinking.
Start by doing simple flow charts of your audiences moving through the feature you want to develop: these user action maps will at least provide a path for deeper questions into back end touch points.
ALWAYS START WITH WHY!
FOR CRYING OUT LOUD.
This seems so obvious but it is one of the most unexplained aspects of agile development.
Why we are even doing this in the first place?
This is more about communication than metric gathering but having some validated data always helps.
Get inputs from the last release, the multiple guys complaining on the phone..
Then communicate this out to the team.
Why we are even doing this in the first place?
This is more about communication than metric gathering but having some validated data always helps.
Get inputs from the last release, the multiple guys complaining on the phone..
Then communicate this out to the team.
Photo by m.gifford
GET OUT OF THE BUILDING!
TALK TO THE PEOPLE WHO USE YOUR PRODUCT!
If you want to truly get value in development it means escaping the confines of the office
Find your users.
Get out and make contact.
discover what they need, how they use your product (keep an ear out for completely out of the box usage scenarios! This could lead to new products of markets), their pain points and how critical they are.
Because truly excellent products don't nesseccarily DO everything; they solve a specific problem, and they do this well.
Face to face is always good as you can build mental maps of the types of users you have and their demographic.
Find your users.
Get out and make contact.
discover what they need, how they use your product (keep an ear out for completely out of the box usage scenarios! This could lead to new products of markets), their pain points and how critical they are.
Because truly excellent products don't nesseccarily DO everything; they solve a specific problem, and they do this well.
Face to face is always good as you can build mental maps of the types of users you have and their demographic.
Photo by dailydoseofjoshy
SEND OUT A SURVEY
UNCOVER HIDDEN USERS AND DEPENDENCIES
Another method for understanding your user base and their pain: leverage electronic tools.
Use tools like Fluid surveys, survey monkey, to gain deeper insights abut how your product is used.
Use point of context tools like Get Satisfaction, or User Voice to get indepth on the spot feedback about problem areas of your offering.
The bottom line here is as the largely unknown creator of Work Simplification, Allen Morgensen once very sagely said
"work smarter, not harder"
factoid: most people thought that was Scrooge McDuck.
Use tools like Fluid surveys, survey monkey, to gain deeper insights abut how your product is used.
Use point of context tools like Get Satisfaction, or User Voice to get indepth on the spot feedback about problem areas of your offering.
The bottom line here is as the largely unknown creator of Work Simplification, Allen Morgensen once very sagely said
"work smarter, not harder"
factoid: most people thought that was Scrooge McDuck.
Photo by DaveCrosby
STORY MAPPING
CREATE A BIG PICTURE FOR RELEASE PLANNING
Quick quiz:
Who of you has a clear big picture of all the feature and function groups of your product?
Who knows about Story Mapping?
Who uses it?why do you use it?
Story mapping is a system overview. It's a lean way of doing BD/BRUF...
and a tool to validate the features of your MVP..
and a way to ensure you focus on the right things that bring value to your business and users now..
and a release plan.
Its big and visual, and it's hard to forget about parts of your product if you have one of these in your team area.
Who of you has a clear big picture of all the feature and function groups of your product?
Who knows about Story Mapping?
Who uses it?why do you use it?
Story mapping is a system overview. It's a lean way of doing BD/BRUF...
and a tool to validate the features of your MVP..
and a way to ensure you focus on the right things that bring value to your business and users now..
and a release plan.
Its big and visual, and it's hard to forget about parts of your product if you have one of these in your team area.
Photo by Peter Hellberg
FLOW MAPPING
ATTACHING STORIES TO EVENTS AND DECISION POINTS
Blog post: Mike Lowery : Evolving the story map
http://nomad8.com/evolving-the-story-map/
Flow mapping is a flowchart on steroids.
http://nomad8.com/evolving-the-story-map/
Flow mapping is a flowchart on steroids.
THINGS TO REMEMBER
- Splitting into user roles e.g. Admin, anon user etc
- Focus focus focus! One process per map e.g. Payment
- You can add the layers of enhancement for anything beyond the MVP
But it also needs love. and attention
it is a living breathing piece of documentation.
it is a living breathing piece of documentation.
Photo by Hot Grill
D.O.R.
ON YOUR MARKS.... GET SET....
It is critical that the team understands what is being asked for in order to maximise value delivery.
If you as POs introduce PBI’s that are not ready to be worked on or PBIU’s that contain ambiguity, waste occurs. Waiting time = waste. emergent requirements go up.
BUT this is not Big analysis. This is a simple sanity check to make sure that you have uncovered the most important things like:
- Do we need infrastructure?
- Do we rely on effort outside the team?
- if we interact with data; does it need any kind of validation?
And most importantly: ARE THERE ACCURATE AND ACHIEVABLE ACCEPTANCE CRITERIA.
You can make it as exhaustive or as simple as you like but understand that you might not have to actually DO all the things on this list.
As long as the conversation has been had that says "nope we don't need it." Or "omg we are 3 servers short" the the DOR has done its job.
a little bit goes a long way to increase quality and productivity.
If you as POs introduce PBI’s that are not ready to be worked on or PBIU’s that contain ambiguity, waste occurs. Waiting time = waste. emergent requirements go up.
BUT this is not Big analysis. This is a simple sanity check to make sure that you have uncovered the most important things like:
- Do we need infrastructure?
- Do we rely on effort outside the team?
- if we interact with data; does it need any kind of validation?
And most importantly: ARE THERE ACCURATE AND ACHIEVABLE ACCEPTANCE CRITERIA.
You can make it as exhaustive or as simple as you like but understand that you might not have to actually DO all the things on this list.
As long as the conversation has been had that says "nope we don't need it." Or "omg we are 3 servers short" the the DOR has done its job.
a little bit goes a long way to increase quality and productivity.
Photo by tableatny
D.O.R.
- Keep near the visual workspace for easy reference
- Better to make releases plentiful, and high value than huge
- Use top two lines for themes then epics
- Horizon slices for releases
- Vertical stacks for increasing enhancement within the feature group
Think of how your END user travels thru the system, the roles and system interactions that get triggered by events.
This is inteneded to be small picture thinking. A detailed view on a single user journey
Attach your stories about these interactions to the parts of the map.
Rememeber to find a cool way to mark done. just like the story map.
This is inteneded to be small picture thinking. A detailed view on a single user journey
Attach your stories about these interactions to the parts of the map.
Rememeber to find a cool way to mark done. just like the story map.
MOVING PAST BDUF:THE CHALLENGES
- Understanding the concept of "Just enough, Just in time"
- Unknowns are actually ok!
- Writing user stories without getting technical
- Letting go of the how, focusing on the what
- Domain knowledge for the other software specific skills e.g. UX, UI design, prototyping
- and finally....
Like any big change it will take patience and hand holding.
It will take the SM and the PO colab on Story writing coaching and estimation games, and expectation setting.
But i have seen Traditional BA with 25 years indentured in the same job embrace this change and totally rock it.
The point is: none of these hurdles are insurmountable.
It will take the SM and the PO colab on Story writing coaching and estimation games, and expectation setting.
But i have seen Traditional BA with 25 years indentured in the same job embrace this change and totally rock it.
The point is: none of these hurdles are insurmountable.
Photo by Daniel Kulinski
Collaborate
Collaborate
Collaborate
Photo by bibendum84
KEEP IN TOUCH :-)
@miss__haley
Find my profile, LinkedIn and various other vices here :-)
Photo by bubbo.etsy.com
