Archive for the ‘Business Analyst’ Category

Announcing the release of Discover to Deliver: Agile Product Planning & Analysis

Tuesday, September 25th, 2012

by Mary Gorman and Ellen Gottesdiener

We are pleased to announce our book Discover to Deliver: Agile Product Planning and Analysis is now available.

Discover to Deliver provides the essential planning and analysis practices you need to collaboratively deliver high-valued products. It gives you a visual language to streamline and simplify your planning and analysis. You and your team get practical guidance in how to collaborate continually to discover and deliver an evolving product. Continue reading | 6 Comments

Structured Conversations at Agile 2012

Saturday, August 11th, 2012

What really is value? How do you get diverse stakeholders with sometimes conflicting views of value to obtain—and sustain—a shared understanding of product needs?

We discussed these questions and more with Tech Target’s Melissa Webb. Melissa interviewed us to learn more about our Agile 2012 tutorial The Product Partnership: Using Structured Conversations to Deliver Value.

Melissa’s interview synthesizes a number of the key concepts in our new book, Discover to Deliver: Agile Product Planning and Analysis, which will be released at Agile 2012!

You can read the complete interview here.

Going to Agile 2012?

We’re also pleased to be delivering workshops, each chock-full of learning activities:

That Settles It! Techniques for Transparent and Trusted Decision-Making on Your Agile Team Wednesday morning, August 15, 2012 with Ellen Gottesdiener.

The Contracting Two-Step: Patterns for Successful Collaborations, Wednesday afternoon, August 15, 2012 with Mary Gorman.

Hope to see you there! Continue reading

Experiencing Agile: 6 Agile Planning and Analysis Practices to Try

Monday, May 14th, 2012

What practices can you adopt to help your team experience Agile?

This question was raised by a listener to the podcast we recorded on agile analysis practices with BA coach Yamo. (Find the podcast here.) The specific question that Katie Metcalf asked us was this:

“What Agile techniques would you suggest introducing to a software development team that is currently not using the Agile approach but would like to get a flavor for the methodology?”

Agile Analysis, Agile Testing: Synergies for Successful Software Solutions

Friday, March 16th, 2012

My experiences working with agile teams have taught me that agile analysis and testing skills are truly synergestic.

So much so, that I put together a tutorial for the April 2011 Quest Conference (Quality Engineering Software & Testing) entitled, “Requirements Exploration with Tester Collaboration”. Subsequently, I had the honor to work with agile testing guru Janet Gregory to present this at Agile 2011.

Next month, EBG’er Sue Burk will co-present this tutorial with Janet at Software Testing Analysis & Review (STAR) conferences. So, you might be wondering, what are those synergies?

The Testing Mindset

Product needs evolve into requirements that define what will be built, what will be tested, and how the product needs will provide value for the organization. People with testing skills need to be involved in requirements for the same reason the other product stakeholders need to be involved: to boost the team’s ability to deliver a high-quality product. Continue reading

This Week’s Business Analysis and Requirements Workshop: 2 Days of Learning in Las Vegas

Tuesday, June 7th, 2011

I was recently interviewed by SearchSoftwareQuality editor Yvette Francino about this week’s Business Analysis and Requirements Workshop at the Better Conference/Development Conference this week in Las Vegas, Nevada (6-7 June, 2011).

Yvette asked me to explain the logistics, if we would be emulating gathering requirements for a particular project and if the workshop be relevant regardless of domain area. Here are my answers: As conference chair, Continue reading | 1 Comment

Agile Product Needs book: Sneak Peek

Wednesday, February 16th, 2011

Mary Gorman and I are in the midst of writing a book.  The title is still a WIP (work in process). A couple of contenders are “Agile Product Needs: <subtitle1:> ” and “The Agile Product Partnership: <subtitle2>”.  We’ll be looking for your help on settling on a compelling title – stay tuned, we can use your creative inspiration!

Our goal is to provide practical guidance on challenges agile teams face. Wrestling the “right” user stories out of the product backlog. Slicing user stories into “right-sized” chunks so they are ready for estimating and planning. Deciding on the next high-value product needs for delivery. Planning more than two weeks ahead (realizing you need a longer time horizon). Using acceptance criteria and examples to deepen shared understanding. Exploring product needs in a holistic way. … Continue reading | 5 Comments

What Inquiring Minds Want to Know: 120 Brains, 30 Minutes, 13 Themes

Thursday, January 13th, 2011

What Tough Agile Analysis Questions Do Business Analysts Need Answered?

This is the question I posed to the participants in a facilitated workshop at the Building Business Capability Conference (BBC) 2010 this past fall. The BBC conference, held in the Washington, D.C. area, was the first official IIBA ® conference. It offered tracks for business analysis, business rules, and business process management.

Context for the “Tough Agile Analysis Questions” Workshop

As the facilitator, I had 30 minutes to “crowdsource” from an energetic, curious, and motivated group of 120 business analysts. Many analysts in attendance were new to agile practices. All of them cared deeply about the value of business analysis. They were eager to… Continue reading

Lessons on Collaboration: Retrospective on Delivering the IIBA BABOK, Part 1

Wednesday, March 17th, 2010

What are good practices for delivering a complex product for a broad global customer with a group of volunteers scattered all over the world?

This is a real-world question for me right now: I’ve volunteered to participate on the Agile-BABOK® (Business Analysis Body of Knowledge) addendum effort. Like the BABOK itself, this addendum can impact the practices of a broad worldwide community of professionals.

Learn From Those Who Have Been There Before

Two groups have tackled the problem of using volunteers to deliver an industry standard, so I figured we should “learn before we burn”. One group is the PMI Agile Community of Practice group, and the other is the BABOK Body of Knowledge Committee.

Ideally, learning what worked for these groups, along with their suggestions for what they would do differently were they to do this again, could help the Agile-BABOK addendum effort to start smart: leverage what they’ve found works, avoid or mitigate what didn’t work, and adjust their practices based on their experience. Continue reading | 1 Comment

How Agile is Influencing the Traditional Business Analyst Role Part 2

Tuesday, March 2nd, 2010

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 | 1 Comment

How Agile is Influencing the Traditional Business Analyst Role: Part 1

Wednesday, February 24th, 2010

How is Agile influencing the traditional role of the Business Analyst? What will the future hold for people with business analysis skills? A Modern Analyst writer for an upcoming article posed these and other questions to me.

Because the final article will be an amalgamation of responses and not contain my full set of responses, I’m sharing them here with you, in two parts.

Let me know what your reactions are!

Since the term “Agile” is used in so many contexts, what does “Agile” mean to you?

I assume in this article you are focusing on agile practices for product development (and not “agile” as a marketing term—e.g., “we’re an agile business”). Recognizing that a product can be software, hardware, a complex hardware and software system, or business process change, I would turn to the Agile Manifesto and its underlying principles.

It is striking how humanistic and pragmatic the manifesto and its principles are: “individuals and interactions” and “customer collaboration” are valued along with “working software”; the twelve principles include responding the “changing requirements” and frequent delivery along with simplicity, technical excellence, self-organization, and reflection.

When you study the history of software engineering and software methods, you discover that many of the practices that fall under the “agile” umbrella are not new. We stand on the shoulders of those who have written, researched, and experimented with good practices. We should not forget our history.

Studying those practices and history is informative. The agile “movement” will fade, and the most useful agile practices will become mainstream. I think Alistair Cockburn was spot-on at the Agile 2009 conference, when he said his keynote was about “burying agile, not praising it”; that is, people aren’t arguing very much about agile. Most of the theoretical issues are settled. Now we’re focused on how to implement agile practices.

Remember when structured development methods, and then information engineering, and then object orientation were the hot topics and next silver bullet? Take object orientation: object technology is a common lingua franca for developers. It’s been assimilated.

The same thing will happen with agile. Iterative development, timeboxing, or kanban-like flow models for development (continuous integration, test-driven development, user-acceptance-driven development, or BDD, behavior-driven development)—all this will become common practice.

Even “classic” agile is changing. Some people are adapting lean practices, others are figuring out how to address agile/adaptive architecture, and the software craftsmanship movement is pushing for attention.

So, to sum up with the keywords that inform my work—the ones that pop into my head when I think about agile—I would name these: customer collaborative, business value, adaptive, self-reflection, incremental, and iterative. Continue reading | 2 Comments