I’m in the midst of a series of posts taking a look at the business analysis process through an agile lens.
One purpose of those posts is to compare more phase based approaches to product development (derisively referred to as “waterfall”) where there is an explicit analysis phase with more iterative approaches where analysis activities are spread out throughout the initiative.
Another purpose is to show that the “agile” in agile business analyst really should be thought of as an adjective. It more describes how you approach a particular role than creating an entirely separate role. (Although many organizations that use that term don’t necessarily see it that way)
Finally, I wanted to show where business analysis activities are still appropriate and useful when you’re working in an agile fashion. You just need to change why you use the techniques, the extent to which you use them, and when you use them.
The particular step covered this week is define the detailed requirements, which is an activity that is most often associated with business analysis.
When you work in an agile fashion, you want to dig into specifics of your backlog items just in time. That activity is often referred to as backlog refinement, and business analysis techniques are very well suited to help you do that.
This week’s resources take a look at understanding the details of your solution, the concept of backlog refinement, and a little bit of philosophy on if there’s such a thing as agile requirements.
How agile business analysts build detailed understanding
This post is the sixth in a series of posts on the agile business analyst. This one explores how to build a shared understanding about the details of your solution.
What You Ought to Know about Writing User Stories
A set of resources about the key aspects of writing user stories. These are things people forget when they obsess about writing user stories “just right”.
Backlog refinement is when the product owner and some, or all, of the rest of the team refine the backlog on a regular basis to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.
How to describe user stories to build shared understanding
Some techniques you can use to describe user stories to help you build shared understanding of your product and the outcomes you seek.
Is there such a thing as agile requirements? Does it matter?
Karl Wiegers shared an article that he and Joy Beatty wrote titled Agile Requirements, What’s the Big Deal. The article brings up some good points, and the conversation that ensued on Linked In is entertaining as well.
My take on the topic is that whenever you see agile modifying a commonly used term (such as agile requirements, or agile business analyst for that matter) treat it as an adjective rather than a noun, and question whether the modifier is really needed.
Sometimes the modifier is added simply for the benefit of attention and SEO. (And now you know the dirty little secret of my “agile” business analyst series )
Thanks again for subscribing to Inside Product.
If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.
Plus if you think someone else would get some value out of the newsletter, let them know they can sign up and get a free copy of Product Ownership in the Wild.
Talk to you next week,
Kent J. McDonald
Founder | KBP.Media