Skip to main content

Tag: Career

Why Are We Still Talking About the Role of the BA and PM on Agile Projects?

Written by Angela Wick on . Posted in Articles.

It seems like we have been talking about this for 10+ years! We probably will continue the discussion for another 10!

Titles cause confusion. As Kupe’s blog talked about last month, confusion still exists regarding the PM and BA roles in general. The industry works hard to clearly define these roles, but the real-life challenges of organizations make perfect alignment to industry role definitions impossible. And, more recently, agile roles have been added to the mix.

As more and more organizations transition to an agile mindset, new roles get added to the mix, causing even more confusion. When I work with emerging agile teams, common title and role-related questions include: 

  • Do agile projects & teams have BAs?
  • Do PMs become Scrum Masters?
  • What is the BA’s role on an agile project?
  • Is the Scrum Master the same as a PM?
  • Do BAs become Product Owners?
  • Is the Product Owner a SME or a sponsor?
  • Is QA part of the agile team or are they separate?

We really need to stop asking these questions! When organizations all define these titles differently to begin with, how can the industry answer this for everyone? We need to stop trying to draw lines from traditional titles to agile titles. It doesn’t work—there is no direct translation—no 1:1 conversion. We get frustrated because this is the mess going on in our minds:wick May12

Real people work on agile teams, not titles. What strikes me when I hear the role confusion questions about agile is: Did we have hiring managers searching for Scrum Masters and Product Owners before? No, these are simply new titles that have been popularized by the common agile team member roles.

These may be newer roles or titles for organizations implementing agile, but that does not mean that they are completely new people. So, where have we been getting the real people for these roles? From PMs, BAs, Tech Leads, Solution Architects, Business Managers and Product Managers—people with experience in traditional roles. Many times, their titles are not changing! So, by formal title I can be a Business Manager and play the role of a Product Owner on an agile team. I can be a BA by title and be part of an agile team, where my role depends on what the team needs and what talents I bring to the team.

The same tasks need to be completed on agile and traditional projects, but the timing, format, and accountability changes as well as the definition of “done.” The agile team determines these aspects by applying agile principles to determine what will add the most value to the process and the customer.

As BAs and PMs we always ask our stakeholders “why is something done” and we dread the common “we have always done it that way” response. We need to ask ourselves the same question about our work. Why do we do what we do? Can it or should it be done at a different time, in a different format, at a different level of detail, as a team instead of as individuals, to get even better results?

If we can let go of titles and focus on skills, techniques, and continuous improvement, we can minimize the confusion involved in the transition to agility. Let’s stop asking where the BA or PM fits into agile and start looking at real people who have a mindset needed to collaborate and successfully deliver value to our organizations!

Our mindset needs to shift to something like this:wick May12 2

The same basic skills are required for every software development effort—it’s how and when you apply them that varies. How can you apply agile principles to your organization to inspire innovation and maximize value?

Review the agile manifesto and the agile principles. Don’t ask where the BA fits or how the PM role changes. Focus on building a team with skills that align with agile principles and question how your approach to work aligns with the principles:

  • How do we promote consistent and continuous teamwork and collaboration?
  • Are we constantly focusing on value in everything we do?
  • Are we focusing on dialog and discovery over process and documentation?
  • How do we encourage people to let go of job descriptions and empower them to jump in and help as needed with a variety of roles and responsibilities?
  • Do we have team members with facilitation skills that create a sense of shared understanding and make stakeholders feel safe, knowing prototyping, iterations, and collaboration often can replace reams of paper?
  • Do we have team members who can elicit, identify and communicate requirements?
  • How do we manage and adapt to change? Do we have team members who are rigid or flexible?
  • Who are the people in our organization with strong vision?
  • Which people in our organization can help groups simplify, prioritize and make progress?
  • Do our team members have the leadership skills needed to self-organize?

This transition to an agile mindset can be difficult for traditional organizations.

Why? Organizations, especially large ones, are defined by their structure. Titles and processes provide the foundation for accountability (job descriptions, hiring, performance evaluation, termination, etc.). So, the real driver of difference here is that agile commands us to think differently about accountability and structure, and how we deliver value. The agile mindset demands:

  • Flexibility: With a focus on continuous improvement, the roles and responsibilities of agile team members need to change with the needs of the customer, the team, and the business environment.
  • Equality: Agile principles limit hierarchy and job descriptions. The team rolls up their sleeves and works together providing whatever skills are needed to bring value to the customer.
  • Continuous Collaboration: To consistently deliver working software in short timeframes, agile team members need to stay focused. Job titles and responsibilities outside of this focus might need to be restructured if they divide the attention of a team member.
  • Customer Satisfaction: Customers need to be available to consistently collaborate, preferably face-to-face, with the agile team and to review regular releases of working software/products.

The more we try to place accountability on individuals/roles/titles the less agile we really are. This does not mean there is not a role for BAs and PMs on agile teams. Instead, it means we need to rethink how we define role or title. We need to define them by focus, mindset, and objectives, not by documents and individual accountability. Agile is a transformation, at an organizational level, that challenges teams and organizations to think, act, behave and lead differently.

We also need to understand what tasks and processes should remain outside of the core team. Too many organizations try to fit every project task into an agile framework, which often limits their agility. Supporting and overhead tasks like audit, governance, documentation, training, etc … if needed, can be done by a supporting or partner team. This allows the core team to remain focused on product value and delivery.

What do you think? Are titles getting in the way of your organization’s transition to agile? How do you find the right people/skills for your agile teams? Please leave your comments below.

Don’t forget to leave your comments below.

The Agile BA: For An Agile Team, You Complete Me

Written by Bob Woods on . Posted in Articles. 2 Comments on The Agile BA: For An Agile Team, You Complete Me

It’s a fantastic invention really.

It most likely was derived out of sheer necessity and in some cases desperation. In many varied situations you can pull from it a wide array of tools which will get the job done when you need it most. It’s a versatile, useful, multidimensional asset; a must have for those who dare to brave the unknown.

Swiss Army Knife? No…but that’s kind of cool too.

I’m talking about the Agile Business Analyst.

I chuckle a little inside when I hear the contrast between some Agile ‘purists’ and Waterfall BA’s who live on different islands when it comes to the Agile team roles. On one side you have the self-proclaimed ‘agilista’s’ who evangelize the rainbow and lollipop world of completely cross-functional teams, with each team member well versed in development, testing, analysis and project management.

I personally feel that these individual folks got into their specific line of work for a reason. (Don’t get me going on this ‘BORG’-like scenario where everyone can, at a high level, perform all functions when needed. I have yet to witness it in real life.)

On the other side you have traditional BA’s saying, “Where do I fit in here? I don’t want to code. I can test but don’t want to do it as a career. I like my BA job just fine but don’t want to limit myself to traditional methodologies. Where do I fit in the Agile world?”

Ladies and gentlemen, I give you the Agile BA.

Let’s take a moment to break down why this role is so crucial to an Agile team.

Imagine a far-fetched scenario where your technical experts aren’t great communicators (there’s that smile). Imagine another far-fetched scenario where Product Ownership isn’t 100% dedicated time-wise to the team. Throw in just for giggles the idea of an over-utilized QA team that is viewed as a bottleneck in quick to market delivery. Oh…and by the way…we are Agile and assume we don’t have to document what we do (no matter what SOX, HIPPA, FTC, ISO or anyone else has to say).

To summarize, we have poor communication between business reps and development regarding needs, poor quality due to overworked and under-appreciated QA, and compliance/legal/information assurance breathing down our necks because they need something, anything, showing we actually are thinking through how we handle data.

For some, this little picture painted here might represent exactly where you live now! For others it may paint a picture of where you see yourself headed.

I give you the Agile BA.

Let’s start with the developers. They need someone who can talk business-eez and translate that into technical jargon. They can’t get the PO to spend any dedicated techie time with them but the need is still there on a somewhat daily basis. Now, don’t mistake this to say the BA should play the PO role. One voice makes the call on value and priority in the backlog. But an Agile BA will have a great relationship with the product owner and help create a bridge between the two by becoming a business to IT translator.

The most common area of success I see in this “translator’ role is when teams practice the “Three Amigo’s” approach to development. This is where a developer, tester and BA will sit down and hammer through the known details of each story before any actual work is done.

Ever needed something from someone who spoke another language? Remember that feeling of utter relief you felt when the Good Samaritan who could translate stepped in to assist? They didn’t tell you where to go, but they could sure help in getting there.

I give you the Agile BA.

How about our testers; our QA brethren? They are the ones who get code at hour 11. They are the ones who are pushed to sacrifice quality for time. How can our Agile BA assist?

Being as familiar as they are with the backlog of work, requirements, and business/technical needs, they are ideally suited to assist in some of the higher level testing efforts that will help ensure new levels of quality. They are careful not to encroach into the technicalities surrounding the QA world, but make themselves available to QA as an additional resource to ensure completed requirements before passing on to their PO for final approval. They are many times best placed as a final set of eyes to keep the team from the burden of unwanted rework. In this scenario I have seen the BA become the product owner’s right hand (wo)man.

QA can feel a little on an island at times. They are the bearer of bad news and the messenger is often killed in these circumstances. They need someone to help evangelize quality and point out what we will simply call ‘opportunities for improved code design’.

I give you the Agile BA.

Finally, agile documentation (not an oxymoron).

There are companies out there, who I won’t address by name, which have refused to adopt Agile approaches due to the perception that their compliance level will be at risk (no pun intended) because of the perceived lack of sound documentation in Agile practices.

It’s important to remember that great Agile teams will do what is needed to provide the business with top value. If the business has determined that a certain level of documentation is required in order to continue to provide this kind of value, than the Agile team had darn well better plan for that documentation need.

Working software is, according to the Agile Manifesto, of considerable value to the business. But remember that the manifesto does not say documentation is without value. It simply states working software is considered of more value.

Well…yeah… of course. We want the software, predominantly. But real world tells us that we need to prove compliance and best practice data security. It’s hard to do that with a poorly written user story!

I give you the Agile BA.

With their day-to-day involvement on the Agile team, inclusive of the product owner, they are ideally placed to help define which parts and pieces will create the most value from a documentation standpoint. They can work with the team facilitator/scrum master/etc. to find out who needs what, and then help translate that into streamlined and useful (valuable) documentation.

Funny thing is the teams I’ve worked with find the Agile BA to be one of the most critical roles on the team! We can swap out a developer if need be. Rotate the testing around a little if you must. But please, PLEASE don’t take away our business analyst!

There is a side effect though. Our Agile BA’s are often asked eventually to become product owners themselves. Why?

Well let’s walk through this again…

  1. They have experience in translating business needs to developers
  2. They know what to look for in quality products
  3. They have experience working with business partners in backlog prioritization
  4. They can determine streamlined documentation needs that fit business value
  5. They know what it means to be engaged with an Agile team day after day.

I’ll be honest here…that’s a product owner worth their weight in gold.

Agile is all about providing value. When you look at the many ways an Agile BA provides value to their team, how could anyone question whether or not there is a seat available at the table? The Swiss Army Knife is considered a must have by some (Swiss Army anyone?). It’s flexible, useful, valuable…dare I say…Agile?

Make no mistake, as timeless as that tool is, the time is coming very soon when you won’t see an Agile team without their handy-dandy Agile BA which you will have to pry from their cold dead hands!

Don’t forget to leave your comments below.

BA-elzebubs Glossary Four – The ‘B’s

Written by Marcos Ferrer on . Posted in Articles.

My brilliant readers know this piece of fun. Get credit in my next blog by offering more “B”s (and “C’s”) in the comments at bottom.

BA: See Business Analysis or Business Analyst.

Baseline: 1. A method of slowing progress to fit communal bandwidth; for example, the monthly rhythm of a change control board. 2. A clear, consistent, concise definition of feasible requirements suitable for: a) ruining with last minute executive confusion and “demand” deliverables; or b) for improving with carefully considered change management.

BB: Profession following BA.

BC: See BB.

Benchmark: 1. The mark made on the bench by project teams that watch what others do, similar in value and concept to the “hashmark”. 2. Solution speed comparison tests, as in “Wow, Amazon’s on-line store put us out of business in less than 10 years.”

Benefit: 1. Value that a solution might provide if implemented successfully; 2. The source of stakeholder fear of a solution. Example: “Digital blueprints mean that we don’t have to drive all over the county fetching and delivering blueprints, but driving around is more fun than actually supervising sewer work, on-site, most of the day.”

Best Practice: NOT what you are doing. Believe it. Diagnose it. Now change it. Repeat. Now you’re getting it – oops, not quite! Keep trying.

Beta Test: Formal term describing a solution that is not ready for commercial release, but is released to a limited number of users who help by giving feedback to the developers. Apple modernized this practice by releasing to all users while dropping the “beta” designation and using the word “free” instead. Microsoft is fighting back by moving to alpha releases but continuing to charge money, giving the illusion of product maturity.

Bit: 1. An information technology word never to be discussed with a business stakeholder. 2. A canned response to common stakeholder concerns. Example: “When the stakeholder objected to the process model, the BA bit them in the ear and the stakeholder dropped the objection”.

Box: A polite word for those in an organization who write the checks for “change consultants”. They do this for their own protection. Example: “He wanted Org X to get out of the box, so he hired the change consultant, but it turned out that he WAS the box, so he fired the change consultant!”

BPMN: 1. A notation for modeling a business process domain for stakeholders who can’t pretend to read but have no trouble pretending to understand a picture. 2. An alternative to sticking with text rendered so large that it can be confused with a picture. See PowerPoint discussion by Edward Tufte.

Brief: A highly compensated, highly expensive way of communicating. The most successful executives are brief in their communications (“of course this will be everything you want”) and in their tenures (“good luck, it was nice working at you”).

BS: Business Synthesis. What did YOU think?

Bug: A critical yet unexpected system feature from a developer. These (widely misunderstood) features help ensure that the developer’s software gets tested thoroughly once it is already released. Testing before release is optional – see “Baseline”).

Business: None of yours, hopeful elicitor :).

Business Analysis: The precursor to Business Synthesis.

Business Analyst: Anyone precursing Business Synthesis.

Business, Monkey: 1. The illegal trade in endangered primates. 2. Any decision made in the “C” suite without any sense of the impact on end users.

Business Requirement: 1. As commonly practiced by business executives, a business requirement is any requirement promoted by a “business” person in the organization, suiting the “business ego” needs of that stakeholder, in direct contradiction to BABOK. Example: “When this is over, we will still be a Microsoft shop, won’t we”? * 2. As defined by the BABOK, a business requirement describes the needs of the organization as a whole, and not groups of stakeholders within it. Example: “When this project is initiated, existing systems must continue to operate without additional downtime, as measured by existing availability reports.”

Business Rules: 1. Code buried deep where no businessperson can find it, known only to programmers, who can’t explain it. 2. Arbitrary wants that are un-code-able, as they cannot be explained. Example: “The system should automatically pick the best employee for promotion.” 3. Actual policies that govern transactions and entity relations of great value. These policies are typically kept out of code so they can be modified on the fly by spontaneous human judgment. Example: “No insurance company should carry more than 33% of all liability” is easily modified to add the phrase “unless the insurance company is run by people who assure us that all is OK and besides they are our friends.”

Button: The solution to everything. Examples: “Can’t we just add a button”? or “Can’t the system just push the button for us”?

Enjoy! And give BA-elzebub (not me!) some “C’s” below (Cache, Cynicism, Customer, Cost-Benefit, Critical-Path more) should your Cranium Crave Creative Comprehensibility by Chuckling Colleagues 🙂

Don’t forget to leave your comments below.

Definition-of-Done – Are We There Yet? Part-1

Written by Robert Galen on . Posted in Articles.

Introduction

There are several terms used for it within agile contexts. Sometimes you hear:

  • Done
  • Definition-of-Done or DoD
  • Done-Ness Criteria
  • Acceptance Criteria
  • Release Criteria

Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.

Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.

Done-Ness

Consider done-ness to be the criteria that constrains the teams’ work. If the team were building a bridge, then it would be the engineering rules, practices, inspection steps, local regulations, and completion requirements that would permeate everything the construction team would do. In many ways, the Definition-of-Done should seep into every aspect of agile team collaboration. If agile were a game then DoD would be the “rules” of the game…and the rules would be read, understood, and consistently applied across the team.

I’ve always been a strong proponent of a 4-layer view to done-ness. In this worldview, the layers build upon one another, moving from individual-based work, to story-based word, to sprint-level work, and ultimately to a release. I’ll often use the term “guardrails” to indicate the guideline nature of the criteria in guiding the teams’ efforts. Now let’s review each of the four levels in turn.

Work Product

This is the layer of the individual contributor. For example, your front-end developers should define some rules, conventions, and standards for how they design, develop, test, and deliver their UI code. The adherence to these standards should be defined specifically as done-ness criteria. This same logic applies to each functional role within your agile teams. Everyone should define a set of criteria that surrounds professional delivery of their work products.

  • Who contributes these? Usually there are two sources. Probably the most powerful is each team defining its own engineering rules. So there is a strong sense of uniqueness as you move from team to team. The other source is more organizational. Say for instance you’re working at a large web design shop where there needs to be consistent UI coding conventions and standards across the teams. I would expect “someone” in the organization to define these—and then for each team to adhere to these broader done-ness criteria in addition to their own.
  • Some examples: I literally gave one above, in that you might have UI development standards. Another example could be coding standards for you primary language or technology stack. Still another could be process based, for example, an “agreement” at a team level to try to “pair” as much as possible on each user story OR to have a “pair review” prior to checking in each story.

Story Level

This is the work delivery level. If you are using user stories, then done-ness surrounds defining a rich and meaningful set of acceptance tests per story and then holding yourself accountable to delivering to those functional constraints. Remember, acceptance tests are incredibly useful as design aids and test aids when the team is sorting out the nuance of each story. I consider that the most important part of the acceptance tests—the business logic design hints.

You should also develop clear quality goals at this level. It may sound prescriptive, but I like the criteria that all bugs that have been found in the development of a story to be fixed prior to declaring that story complete. These aren’t legacy bugs, but bugs created and found during the development of the story. I can’t tell you how many times teams run into problems at the end of the sprint in delivering a completed story with no known bugs.

  • Who contributes these? The Product Owner is ultimately responsible for defining the functional conditions of acceptance for each story. However, there are also inputs from the organizational side. For example, agreeing that each story will receive a solid pair-based code review or that a complete set of automated unit tests (TDD) will be developed and running before checking in and “declaring victory” might be decided as overall quality criteria that impacts every team.
  • Some examples: I gave several above. Clearly the story has to meet the Product Owners established acceptance criteria. I also like the notion of the Product Owner signing off on each story. That is, they review it, demo it, and determine that it is indeed—done. Then they physically sign-off on the story. Usually story done-ness also surrounds the design integrity, process steps to develop and test the story, and known bugs.

Sprint-Level Criteria or Sprint Goal(s)

This level is focused towards how well the team has met all of the goals and criteria they set forth when the planned their sprint. A large part of these criteria are typically driven by a successful sprint review or demo. I like the notion of “connecting the dots” between the sprint goal and the sprint review, so the team should think about the goal as a cohesive demonstration of business value from the customers’ point of view.

In my classes I often get asked, can a sprint have multiple goals, i.e. deliver on multiply focused activities? The answer is probably yes, but what the question is really looking for is the ability to say:

The goal of this sprint is to deliver 524 hours of work towards these specific 12 User Stories that are sized at 27 Story Points.

I think this is an incredibly poor goal because of the tactical, work effort focus. For example, there is no “customer” or no “demo description” in this goal. I’d much prefer goals that have a clear connection to the customer, value, and their challenges embedded within the goal. Having 2-3 separate goals articulated in this way seems fine too.

  • Who contributes these? Truly it’s the responsibility of the Product Owner to define or establish a goal for each sprint. I usually encourage them to bring a tentative sprint goal into sprint planning and then align that with the team and the agreed sprint work as part of the sprint-planning meeting. It then becomes a shared and achievable goal.
  • Some examples: If, for example a team were working on an ATM project, then a few related sprint goals might include: Complete single customer sign-on and account interrogation to include balance and transaction lists for the past month. Another one might be: Complete and demonstrate all deposit based activity (single/multi/business) account transactions with receipt printing. Only check deposits will be supported. I hope you see the connection to real-world customer usage scenarios. I’ve found these goals, which have open-ended functional details, to best inspire the team to “solve a problem” versus “deliver a set of stories”.

Release-Level Criteria or Release Goal(s)

If you’ve ever been part of a team that delivered software in more waterfall environments, a common practice is to create release criteria. These are project constraints requirements that are usually established at the beginning or early on in a project. Often they are consistent from project to project or release to release, because they quantify organizationally important criteria. For example, quantifying whether you could release with specific levels of bugs (both in priority and count) or quantifying how much testing (coverage) needed to occur prior to a release.

One of the unfortunate parts of many agile adoptions is that these sorts of criteria have been dropped. I think they’re incredibly valuable in defining meta-requirements or key constraints for the teams to adhere to within each release. Typically they exist anyway within the organization, but calling them out creates a focus on them in planning, execution, and delivery. They’re particularly important in at-scale delivery—so that multiple teams are maintaining a consistent focus on their overall release goals.

  • Who contributes these? Usually they’re defined outside of the team proper. Either being defined by the Product Ownership team or Chief Product Owner as part of establishing the definition of a release. As I mentioned, they often carry-over from release to release. They are typically “not optional”, so the organization needs to be willing to block a release or drop a feature if it does not meet the release goals.
  • Some examples: I’ve already mentioned allowable defects in the release and test coverage as solid examples. Global performance targets or usability constraints are often mentioned in applicable projects—so there is often a focus on non-functional requirements. Process constraints or commitments might also be mentioned, for example, the fact that each user story needs a minimum of 70% automated test coverage before being considered a candidate for your release train.

Getting Done-Ness into your DNA

Creating a list of your Done-Ness Criteria is only the first step. Just because you have created and communicated them, doesn’t mean that everyone is supporting them. The next step is establishing a culture where everyone aligns with and personally supports the criteria. Not just when things are going smoothly, but when the going gets tough as well.

You know that your done-ness has seeped into your culture when the team sees no other recourse but to do things the right way. I’ll share this example from my time leading teams at iContact that illustrates this cultural transformation:

We were a SaaS e-mail marketing software product and our customers used us 7×24. In fact, our weekends were often quite busy as SMB owners worked on their next week email campaigns. There was one weekend where a nasty mail sending component bug cropped up. It brought down our ability to send email, which clearly affected all of our clients. Not only that, when this happened, we would queue the mail. So this started created an endlessly increasing pool of mail that would cause delays even when we fixed the bug.
So the pressure was on.
Our teams would normally assign a “support engineer” for weekend support. The engineer in this case was notified of the problem, looked into it, and devised a repair. As part of our DoD, we’d agreed that no fix or repair could be checked-in without a paired code review. Now keep in mind—this was a holiday weekend, so people were on vacation. The support engineer determined that he needed a review with two others who were experienced in this area of the mail-sending stack.
He found them via text messages and phone calls and they all committed to a distributed/remote code review session on Saturday afternoon. They discussed a few issues and changes related to the repair, and then he completed those adjustments and released the repair.
When I came in on Monday morning I was amazed at how committed the team was to doing a proper review. It would have been the easiest thing in the world to have either checked-in an un-reviewed repair OR waited until everyone was back on Monday. But the support engineer and their teammates were committed to our customers and to their Definition-of-Done. It was in their DNA.

Why Done?

So after all this discussion, you might be asking yourself – why all of this focus on done? Why does it matter?

It matters from several perspectives:

  • It helps with your estimates. Pre-agile methods, I’ve used done-ness like criteria in my teams because I felt that if we didn’t have clarity around what went into completing our work, how could we estimate our work. That’s the very point we’re focusing on here. Clear understanding of what is expected in completing our work.
  • It helps with your quality. It provides guidance to the team surrounding what makes each step or deliverable complete. It focused on quality of the steps. And it amplifies consistency – so that every check-in or deliverable meets a consistent level of completeness.
  • It helps your Product Owner and customer gain confidence as the team delivers. And it’s not just confidence on the individual stories. It’s confidence on the overall plans and teams ability to meet their commitments with consistent quality.

Is it a panacea for any of the above? Of course not! But it is a key driver for some of the core behaviors that agile tries to amplify in teams. That’s why you hear so many agile coaches “harping” on it.

Wrapping Up

I often emphasize Done-Ness as a place for the organizations leadership team to influence the behavior, focus, and results of their agile teams. I encourage them to get engaged with establishing a deep, broad, and relevant set of criteria for their teams. I ask them to align their DoD to the business, customer, and constraints. I sometimes call them “guardrails” because of my view that they can keep the team “safely on the road” in their delivery of business value and results.

Since I see so many sparsely defined DoD’s it the real world, I usually ask for organizations and teams to over define them – risking a bit of prescriptiveness. I’d rather have more clarity than less guiding the teams.

Hopefully this article has helped clarify a view to what done looks like in agile teams. Now go take a look at your own Definition-of-Done and see if you need any adjustments?

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

References

A Review of the PMI’s New Business Analysis for Practitioners: A Practice Guide

Written by Phil Vincent on . Posted in Articles. 2 Comments on A Review of the PMI’s New Business Analysis for Practitioners: A Practice Guide

The PMI recently published its new Business Analysis for Practitioners: A Practice Guide and is making it freely available (at least for a limited time) to anyone who wants to download a copy. If you are planning to write the PMI-PBASM certification exam you may find this useful because it interprets the PMBOK® Guide concepts of scope, requirements, acceptance criteria and stakeholders from a business analysis perspective.

The Practice Guide is aimed at project BA’s who may be involved at any point “ from identifying business needs to solution implementation.” It is intended to address project-related issues about requirements and business analysis. So for all of you who spend most of your time supporting an existing system, or working in continuous process improvement, or if you are involved with strategic business analysis, this publication is probably not for you. However, if you are involved as a BA working on projects, and especially IT system projects, then you will likely find this Practice Guide to be relevant.

With the upcoming BABOK® Guide v3 moving away from the project focus, it makes sense that the PMI would want to fill in the details about project-based requirements management because that is still such a significant problem for most projects.

A Practice Guide; Not a Standard

The stated purpose of the Guide is to “define what business analysis is, and to demonstrate the practical application of the discipline”. It is only a guide, not a standard or a body of knowledge like the BABOK® Guide or PMBOK® Guide. Think of it as a 200 page text book written by a group of folks who really know their stuff, but was not subjected to a thorough review, nor a consensus-based review and revision.

In some ways, this is simpler to read than the BABOK® Guide or the PMBOK® Guide because the various business analysis techniques are described within the context of when they could be applied. With a few exceptions, the Practice Guide just describes the techniques, but doesn’t tell you how to apply them.

Unlike the BABOK® Guide or the PMBOK® Guide, this Practice Guide should be read from front to back. The Practice Guide sees business analysis as inherently being a process, starting with the definition of the business need, and working through the requirements to solution evaluation. The story builds as you work your way through it. When a technique is only mentioned but not described in one of the chapters, it is assumed that you are familiar with it because it was described previously in the book. In some cases, it’s not obvious that the process is not sequential, and less-experienced business analysts may not recognize that the order in which techniques are introduced in the Practice Guide is not always necessarily the order in which they should be applied.

The PM-BA Relationship

One of the features of the Practice Guide is that it clearly spells out how the PMI expects business analysts and project managers and other project participants to work together. Sprinkled throughout the text are Collaboration Points which detail how the two roles should work together. It often assumes that a business analyst reports to a project manager, or is more concerned with lower level details than the project manager, or lacks the experience, expertise or insight of the project manager. It doesn’t really address the dilemma of the person in the role of both the business analyst and project manager.

Requirements

The PMI Practice Guide does not discuss the similarities between needs and solutions, requirements and designs. That’s really too bad because users often come to a business analyst with what they think are requirements but which are really solutions. PMI assumes that we are only dealing with requirements. But some of the examples, such as the use case example, feature model and the report layout example, do not demonstrate requirements, but rather specify the design of a solution.

Documentation

The PMI has always been concerned with documentation and it is no different here. One of the major problems introduced by a requirements document of any sort is that once the project is over, no one seems to keep the requirements documents up-to-date, and so the support teams quickly lose sight of why the solution is the way it is. PMI could have helped to shift the mindset away from text-based documentation of requirements, and moved toward model-based requirements. Instead, they chose to differentiate between models and requirements. This approach could continue to impede the ability of BA’s who support solutions to get access to the requirements that were incorporated into the solution.

Organization and Content

The PMI has defined business analysis in terms of 5 domains:

  • Needs Assessment
  • Business Analysis Planning
  • Requirements Elicitation and Analysis
  • Traceability and Monitoring
  • Solution Evaluation

The Practice Guide explains the major tasks of each domain and the approximate order in which those tasks should be performed, and describes the techniques that could be applied within that domain.

Needs Assessment

This first section provides an explanation of how to understand problems and opportunities, and provides a pretty down-to-earth explanation of how to conduct a situation analysis, SWOT analysis and root cause analysis. Some of the examples are pretty good, and the supporting diagrams are easily understandable . This is a useful step-by-step guide about conducting a needs assessment, with more focus on understanding the problem or opportunity than on recommending a solution.

Business Analysis Planning

The discussion on stakeholder identification and analysis is pretty thorough and serves as a good guide or checklist.

The Practice Guide uses the term “business analysis plan” to refer to all information that is documented regarding business analysis planning decisions, and explains that the business analysis plan works in conjunction with the requirements management plan. The business analysis plan is a part of the overall project work plan, and so must be developed in collaboration with the project manager.

A possible point of confusion for people studying for the PMI-PBASM certification is that the PMBOK only mentions the requirements management plan, not the business analysis plan. The Practice Guide relegates the requirements management plan to a more narrowly focused role which may not be consistent with exam questions. Even the Guide is not 100% clear, since the glossary definition of the requirements management plan doesn’t exactly match what is described on page 46.

The suggestions about what to consider when developing the business analysis plan are pretty extensive, but there is no real help about how to develop the plan. Many business analysts are uncomfortable with such comprehensive planning; the description here could be overwhelming. There is an opportunity to provide some guidance and examples here, I think.

Requirements Elicitation and Analysis

The Practice Guide only describes how to elicit by asking questions, and doesn’t talk about the need to use research or experimentation as primary elicitation techniques, or to corroborate information provided by stakeholders. It pretty well assumes that you can get most requirements by asking the right questions of your stakeholders, even if they don’t know all of their requirements, or may have difficulty articulating them.

The discussion on analysis suggests using a combination of models to understand the requirements, and to identify gaps, and that’s a good thing. It’s too bad that the Practice Guide doesn’t suggest ways that business analysts can collaborate with stakeholders to develop models concurrently with elicitation, since that approach can be pretty efficient, speeds up validation and consensus, and encourages early buy-in from stakeholders.

A useful table is provided on page 90 to categorize the different types of models and the purposes for which you would use them.

There are simple examples of how to use most of the models, and the diagrams are clear and easy to follow. In almost all cases, precise notation is ignored in favour of a clear explanation, and I think that’s a workable approach.

Overall, the discussion of the analysis models seems more appropriate for a systems analyst than for a business analyst. All of the diagrams drift into the solution design, and miss the solution requirements.

The discussion of requirements documentation seems to lose sight of the models, and is biased towards extensive text-based documentation.

The description about writing requirements is pretty thorough.

The suggested techniques for resolving requirements conflicts are a worthwhile read.

Traceability and Monitoring

The PMBOK® Guide exerts a substantial influence on this chapter. The heart of the described approach to traceability is the Requirements Traceability Matrix (RTM), a concept right out of the 1980’s. Yes, it is worthwhile to take a disciplined approach to traceability, but a matrix is a very cumbersome tool for managing many-to-many relationships between requirements, and between requirements and designs, solution components and test cases. A lot of potential overhead is introduced in the discussion about requirements attributes; you don’t always have to use all of these attributes; in most cases, a few key attributes will be all you can handle.

The discussion on managing changes to requirements is also a little outdated because it promotes the idea of doing an impact assessment on every change request before the request can be considered for approval. The trouble with this approach is that at the project planning stage, nobody ever plans enough time to do all of these impact assessments. If there are many change requests, the project team can burn up a lot of project time assessing potential impacts of changes that will go nowhere. What the Practice Guide could suggest is to obtain a preliminary approval before doing the impact assessment to prevent the project from wasting time on change requests that will never be approved.

The focus on the project perspective of change requests misses out on the business analysis perspective of assessing change requests in terms of the impact to solution value after the project is completed.

Solution Evaluation

This section deals with validating the solution, and then evaluating the solution after it is in operation.

Solution validation and acceptance is discussed in-depth, and includes a good discussion of planning considerations to test and validate the solution. Transition planning to support the solution implementation is also covered in some detail.
The discussion about ongoing solution evaluation is limited to the planning that might occur as part of the project work.

About the Team of Authors

I was a little surprised that the PMI chose to have many of the same people who were extensively involved with the development of BABOK® Guide to lead, contribute or review content for this PMI Practice Guide. You would think that such a large organization as PMI with such a global reach would have found a different group of expert contributors. Are these really the only business analysis experts in the world, such that both the PMI and the IIBA must rely on them so heavily? The good news, of course, is that those experts have been doing a lot of deep thinking, sometimes together, about business analysis for several years, and so the resulting product is pretty solid.

Given that the same people were involved in the creation and review of both publications, it should come as no surprise that much of the content is similar between the PMI’s Practice Guide and the upcoming BABOK® Guide v3. Parts of the discussion on Solution Evaluation are strikingly similar in both publications.

One disappointment is that some of the techniques that are described in the Practice Guide are not generally applied business analysis techniques. When I did an Internet search on some of the terms and techniques with which I wasn’t familiar, I was disappointed to discover that the top ranked hits are associated with some of the Practice Guide’s authors’ companies.

Conclusion

The PMI’s Business Analysis for Practitioners: A Practice Guide is a useful addition to your business analysis toolkit if you work on IT projects that follow a sequential lifecycle. Every now and then there is some acknowledgement of adaptive (it really means Agile) projects. It is a first step at extending the requirements process and requirements management practices that are identified in the PMBOK® Guide.

It will likely be most useful to people who are new to business analysis, although even experienced BA’s are likely to get some tips. It is focused on business analysis within the context of software projects, and for BA’s who report to a project manager. Professionals who already have one of the PM certifications may find this to be a useful resource as they try to earn a second certification.

The PMI has indicated that it is planning to produce a consensus-based Requirements Management Practice Standard in the future. This Business Analysis for Practitioners: A Practice Guide, is a good start.

Don’t forget to leave your comments below.