Posts on Business Consulting Training

Agile Requirements by Collaboration

By Guest Blogger Rob Elbourn, Scrum Team Lead working at a major financial concern in UK. Visit Rob’s Agile78 Blog

I recently attended the “Agile Requirements by Collaboration” presentation at Skills Matter lead by Ellen Gottesdiener from EBG Consulting. Here are some of the main points I got from it.

Ellen described how collaboration needs to happen on several different levels of granularity along the way requirements are viewed on agile projects– the product (which establishes the product or portfolio roadmap), the release and the iteration (or work-in-progress).

Exploring these views can occur in several different facilitated workshops, from the roadmap workshop, to the release workshop to iteration workshops. The corresponding requirements that are clarified or driven out from these workshops also appear on different levels – boulder, rock and pebble.

The idea is that the pebbles form your user stories and are driven out at the level of the iteration workshop. Projects can encounter rock sized requirements at the iteration level and suffer a time delay as new pebble requirements are chipped off from them. This brings to question the level of “doneness” for a user story.

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