Archive for the ‘Agile Business Analysis Flow’ Category

Essential Agile Business Analysis

Monday, July 16th, 2012

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!

Are Your Software Development Practices Jumping the Shark?

Thursday, April 7th, 2011

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 expression “Jumping the Shark” was born. When a TV show, or anything else, jumps the shark, you know it’s on its way out.

Our question this month: have any of your software development practices jumped the shark?

For example, are there boundaries around people’s roles? Some organizations tend to confine people to roles such as developer, architect… Continue reading

Analysis Debt, Redux

Saturday, December 4th, 2010

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 task. Referencing our table of Analysis Debt Causes, he wrote, “I see poor requirements work that would result in an inadequate solution, no matter how well [the product] built.” Furthermore, he said, “all the Remedies [in your article] are really requirements best practices.”

I was glad to hear his perspective because it prompted me to… Continue reading | 2 Comments

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