Posts on Agile Business Analysis Flow

Essential Agile Business Analysis

For years and years we’ve coached and trained teams how to elicit, analyze, and manage requirements for software development projects. We also work on projects—so our coaching and training is based on real project work. We’ve just written a book on agile product planning and analysis. Now that so many organizations adopting Agile as the method of choice, what about requirements? Is there a need for analyzing requirements in Agile?

That was the theme of our June Webinar titled (spoiler alert!) “Business Analysis Is Essential to Agile Success” (use training@ebgconsulting.com to login). For our blog eNewsletter readers, here’s the nugget: requirements drive agile teams!

Continue reading

Are Your Software Development Practices Jumping the Shark?

By Ellen Gottesdiener and Mary Gorman In September 1977, the TV sitcom Happy Days had über-hip Fonzie, clad in leather jacket and swimshorts, water ski over a shark to prove his mettle—and at that moment even diehard fans knew that the show was past its prime. They were right. After that episode, ratings plummeted, and the…

Continue reading

Analysis Debt, Redux

Mary Gorman and I wrote an article on analysis debt Better Software. In it, we said that, like technical debt, teams can incur analysis debt by either ignoring analysis (a potential pitfall of agile teams) or overinvesting in analysis (a potential pitfall of traditional teams). In a private exchange, one article reader took me to…

Continue reading

How Agile is Influencing the Traditional Business Analyst Role Part 2

In my earlier post, How Agile is Influencing the Traditional Business Analyst Role: Part 1, I provided the first set of answers to questions posed to me by a Modern Analyst writer preparing a article on how Agile is impacting the traditional business analyst (BA) role.

Here I continue with the questions and my responses.

What are your thoughts? Do you agree?

In Scrum, do you think a Business Analyst could (or should) be the Product Owner, ScrumMaster, or a regular team member?

Yes, maybe, yes, maybe, yes maybe.

In Scrum, we have the product owner “role.” The PO is perhaps the most important (and burdened) role. The PO must conduct a mix of strategic and tactical activities.

Strategic activities are business or market facing—for example, analyzing the market and business case, defining the product vision and roadmap, developing requirements, adjusting the product backlog, and determining delivery plans.

Tactical activities are delivery team facing—for example, specifying the items to be delivered in each iteration, determining acceptance criteria for them, analyzing dependencies between items, and making tough decisions about what will be built to satisfy a given business need, technical risk, and requirements dependencies. Some great business analysts I’ve worked with pitch in to build and run user acceptance tests.

All this takes a lot of knowledge and many skills, and it consumes a lot of time.

On top of that, to fulfill both strategic and tactical activities on an agile project, the business customer needs experience in product development, along with deep domain and product knowledge.

I’ve coached (and trained) teams working on large, complex products, and I’ve seldom known a single business customer who can do these strategic and tactical activities.

That’s why many organizations turn to talented business analysts for help with the day-to-day, tactical decision making on their agile projects. In other cases, someone who was formerly a traditional business analyst will work out the backlog items, suggest the priorities, and then obtain validation from the business PO.

Continue reading

EBG Product Agility Newsletter

Get tips, stories and news on product discovery & delivery

Join our community and receive periodic tips, stories, and news on agile product management, product ownership, backlog and value management, collaboration, teamwork, and more.

Sign up Here