Skip to content

Book Review: Agile Business Analyst

Title: The Agile Business Analyst
Author: Ryland Leyton

Rating: 4 Stars  (more info)

Overview:
“The Agile Business Analyst” is a well named and well written book. The author is clearly knowledgeable about the skills required to be a successful business analyst and demonstrates how these skills can be employed in an Agile environment. He also provides the reader with a good contrast between waterfall and Agile methodologies, what existing skills are transferable, and which new tools that you consider adding to the toolbox.

I have never held the official role of Business Analyst, although one of the great benefits of Agile and cross-functionality is that I have the ability to practice this skill on a fairly frequent basis, especailly when helping the Product Owner write stories. The “Agile Business Analyst” has given me a greater appreciation for the BA role and provided ideas on how I can better support the BA role.

I would strongly recommend this book to:

  • any business analyst who is currently working in an Agile environment
  • any business analyst who is interested in Agile or hearing Agile mentioned in the workplace
  • anyone in the Product Owner or Scrum Master / Agile Coach role in their organization

What I Liked:

  • The Agile Manifesto values and principles are discussed early and emphasized throughout the book.
  • I like the discussion about desk checks and desk kickoffs, which are essentially mini collaboration sessions between team members.
  • I have never seen the “Waterfall Manifesto” before and found it quite humorous. Thanks for exposing me to this geeky comedic gem.
  • The “Skills and Attitudes that Correlate with Agile” on page 27, is invaluable.
  • The view that the business analyst is the bridge between the business group and the technology group and a strong influencer on an organization shift to Agile was both accurate and powerful.
  • The encouragement to increase collaborative thinking is spot on, especially if you want to be a member of a high-performing Agile team.
  • The principles that the author recommend that BAs should keep uppermost in their minds, especially “See the Whole” and “Get Real with Examples” (p. 43)
  • The concept of the card wall and the examples of both a clean and troubled backlog (chapter 11)
  • Emphasis on the benefits and importance of iterative devlopment in an Agile environment (chapter 12)
  • Great discussion and examples about user stories, acceptance criteria, and decomposition. (chapter 14). I think chapter 14 may be the best chapter in the book. There are many ah-ha moments and quotes that I love from this chapter.
  • Explicitly calling out “maximizing the amount of work not done”.  One of the most powerful, and overlooked Agile principles, in my opinion.
  • Talks about the fact the it’s bad practice to use “the system” for user stories. Honestly, I have seen “the system shall” enough for a good five or six lifetimes.
  • The detailed case study was great. What was even more impressive was that it was done in both a traditional and Agile manner, allowing the reader to see the contrast between the two approached.

What I Didn’t Like:

  • I was confused with the “Iteration Manager” role that was mentioned in the book. I believe this role is most similar to a Scrum Master or Agile Coach, but sometimes this appeared not to be the case.
  • It was mentioned that the iteration review should take about 30 minutes. I don’t feel this is accurate and does not match my experience.

Quotes:

  • “Note that, although at no point is the word “requirement” used, there is certainly information being created, developed, and refined. We are just approaching it differently and producing different artifacts.” (p.74)
  • “If you’re used to writing business, functional, and system requirements, you will have to shift your thinking somewhat to really get your mind around the meaning of ‘user story.’..” (p.79)
  • “Agile takes the view that a requirements document sufficient to “throw over the wall” is a needless increment of work.” (p. 80)
  • “Classic functional analysis would result in the requirements’ being written around each of the relevant layers. This is the antithesis of the Agile view because, in and of themselves, the functional components deliver no business value,” (p.94)
  • “The PO is confused; she hasn’t considered anything less than the full feature set.” (p.174). I find this incredibly common and hopefully we as Agile practitioners can help change this paradigm.
Published inBook Review

Comments are closed.