The Product Owner Role - The Business Analyst

If you are looking for a nice summary of the product owner role in a Scrum environment, I recommend checking out an article on ( ). As I type this, I literally haven't read the post beyond the product owner description section because I wanted to jot down some thoughts. In particular, the potential parallels between the product owner role and the business analyst role. 

Snapped this at the Jim Henson exhibit at the Seattle MOPOP (formerly the EMP). I loved the Count as a kid!

Snapped this at the Jim Henson exhibit at the Seattle MOPOP (formerly the EMP). I loved the Count as a kid!

As early as the first sentence in the product owner role description, you see where the two roles differ. The author states "The product owner is the one in charge of the business side of the project." I agree with this and some people might think this holds true for the BA role as well. Fortunately or unfortunately, the business analyst isn't in charge of squat. In many cases, we struggle to control the methods we use to do the job, the work products we use, what tools we can use or the acceptable format of our deliverables. I literally had a project manager tell me once that she wasn't sure she would allow me to speak in a requirements meeting she was driving. This is not uncommon when a BA is assigned to a project that is underway and that project is perceived as struggling. All of this isn't necessarily a bad thing, it is just part of being a business analyst in a competitive workplace filled with capable people that might have strong personalities.

After that first sentence in the narrative however, the authors description of a capable product owner can easily match the same criteria for a capable business analyst. A business analyst that transitions to the product owner role may need to shore up their "take charge" skills. Although, taking charge of something on a Scrum team is normally quite different than taking charge of something in a waterfall environment. I would have to say that a business analyst is better suited for "taking charge" in a scrum environment than in a waterfall one. It all comes down to three words why this is true, “the product backlog.”  

Any business analyst that is capable of managing a robust requirements package should find product owner backlog management an easy transition. They are not the same but they are really close! A well crafted requirements traceability matrix (RTM) can often be directly imported into a product backlog, particularly if that was the intention all along (hybrid environments). A business requirements document (BRD) is basically a product backlog with chunks of narrative in between. 

Now I would like to pivot to the last sentence in the articles discussion on the product owner. This is because this sentence could be lifted directly out of the product owner context and placed into the business analyst context without a quite little modification. 

That sentence reads, "To effectively function in this role, it is paramount the PO come equipped with great business skills as this is pertinent for decision making and profitability actions."

© 2017 Dwayne Wright 

Vendors And The Business Analyst

It was a long time into my business analyst career before I became a critical part of the vendor selection and vendor assessment process. In fact, I discovered that I was under prepared when it happened because I assumed this area was primarily nestled within the project manager role. This assumption was reinforced because many project managers feel the same way about it. 

A selfie we took during one of the stops on the Woodinville Wine Ride last month. Weekend group bike rides are becoming a staple for us!

A selfie we took during one of the stops on the Woodinville Wine Ride last month. Weekend group bike rides are becoming a staple for us!

Although the word "Vendor" appears just once in the BABOK table of contents (10.49 Vendor assessment), the BABOK does include plenty of areas that touch on vendor relationship related topics. For example, 

2.4 & 9.5 - Vendors can be considered stakeholders and therefore linked to many stakeholder related tasks and techniques. A BA may need to have strong vendor interaction skills, particularly in cases where a "throw it over the wall" RFP process is NOT being used.

5.3 - Vendors can be linked to costs and costs can be used in multiple prioritization processes. 

6.1 & 6.2 - The vendor(s) related to a process can often be the subject of the "as is" state analysis. In fact, the poor performance of a vendor(s) can be a driving force in finding a superior "to be" state.

7.5 - Vendors and the services they can provide are often included in the design process to model requirements. A vendor may have their own requirements and that often translates into a constraint to be noted on the business analysis side.

8.1 - Vendor performance can often be a strong factor in measuring the performance of a solution. In some cases, it can be negative but it can be a positive consideration as well. Think of the common "build vs. buy" decision, a strong vendor can often swing the decision into the buy fork in that decision branch.

11.3 - The information technology perspective discussion in the BABOK is obviously full of vendor related topics and the business analyst should take into consideration on all IT related endeavors. IT is a true ecosystem and vendors are a big part of the overall health of that environment.

So if you are a business analyst that hasn't had a lot of vendor related tasks come your way yet, it certainly could be part of your future!

© 2017 Dwayne Wright

The Documented Rationale Behind Performance Requirements

All to often, performance requirements are stated without including the rationale behind them. Although this isn't a front line risk when it occurs, it definitely can have an impact on shared understanding of what the performance requirement really means to the overall solution evaluation. 

A mobile system takes 13 seconds to load after the splash screen appears and the target requirement is less that 5 seconds. The actual measurement is almost three times longer than the specified performance requirement. That sounds pretty bad, doesn't it? How about looking at the same reality from a different viewpoint? The system takes 8 seconds longer to perform than expected. Now the very same condition sounds almost trivial and we should move on to more important things. 

Last Sunday (July 16, 2017) I finished my first Seattle to Portland bike ride. My single performance requirement was to finish.

Last Sunday (July 16, 2017) I finished my first Seattle to Portland bike ride. My single performance requirement was to finish.

Why does this requirement and the associated fulfillment of this requirement matter? If the target user opens this mobile application 10 times a month, they have lost a full 80 seconds of potential productivity that month. How many of us wait more than 80 seconds each day to get a cup of coffee? So can we say this performance requirement is unnecessary and has no real impact?

After all, how many development man hours would be spent to fulfill the less than 5 seconds launch to ready to validate this performance requirement? A developer would need to analyze the potential bottlenecks, research potential fixes, implement the fixes, test and then repeat this loop until they achieve success. Then that fix can be incorporated into part of the overall release cycle. This could easily run into 20 hours of overall development time and that is time that could not be used to fulfill other requirements. If we assume that developer time is $50 in house or $100 external, the fix will cost anywhere from $1,000 to $2,000. So we are investing $250 per second to improve screen loading time, is that right?

No, because where are not taking into account our full user base and so the cost per second value proposition is much more reasonable. However, this narrative is on its fifth paragraph and I still haven't submitted any real reason why this matters. In fact, we might have even forgotten about our "why objective" because we have been so caught up with the math.

Here is a potential definitive reason why the unusually slow load time for this mobile application matters. This is because the user might think to themselves every time they have to stare at the screen for the full 13 seconds, "this mobile application is a bit of a turd." "Why does it always load so slow, when all my other mobile applications load so much quicker?” "Doesn't this company know that I have better things to do with my life that stare at their company logo while this turtle of an application loads?"

The rationale behind a quick loading mobile application is that we want the users to have the impression we are speedy. If I finish 8 seconds behind you in a marathon race, the difference hardly matters. However, you don't want your customers to be reminded 10 times a month that you are slow. If we don't document the rationale behind performance requirements, they can easily loose their power and support in the development pipeline.

So this performance requirement is not about performance, it is actually about our brand image. Every interaction with our mobile application can easily modify our users future expectations of us. We want to build a consistent track record of exceeding expectations, do we not?  

© 2017 Dwayne Wright

Maryanne Struggles With Stakeholder Meeting Attendance

Maryanne is faced with a decision and she doesn't like most of her options. She is assigned a project that is very important from a compliance perspective but seems to have little operational value. In fact, some may consider it a threat to operational task velocity and would like to see this project fail. 

The Rain Run a few years ago, this is NOT Mr. Middlebottom in front of me but (well you know).

The Rain Run a few years ago, this is NOT Mr. Middlebottom in front of me but (well you know).

Maryanne is in a tricky position because she has limited freedom in building her requirements package. That limit has a name, in fact it has a first name, last name and she assumes a name that fits in the middle. The name of her constraint is Drew Middlebottom and he is the assigned project manager for this endeavor. 

Mr. Middlebottom not only doesn't understand the value of the business analysis role, he obviously considers it a low level threat. He has stated his viewpoints that the process of building requirements takes up to much time. He lobbies for agile methods but that is a smoke screen. He understands and appreciates agile approaches slightly better than he appreciates a business analyst. He uses this as a shield to do what he wants on projects and finds defined processes an irritant. 

The project manager decided that Maryanne would be allowed three workshops in the next two weeks to gather requirements and complete the requirements package. This is a horrible idea but Maryanne's options are quite limited. It is uncertain if Mr. Middlebottom's constant negative campaigning against business analysis activities to the project schedule was a factor in each meetings low attendance but Maryanne knew she couldn't focus on that distraction. She needed to find a way to build a valuable set of requirements and she would likely need to be creative in her approach. 

Maryanne looked at the list of options she had been struggling to create. She didn’t know which aspect of this endeavor was the most depressing. The fact that the list seems weak or that she had invested almost half a day building it. The list of her options she felt were reasonable included:

1. Escalate the issue to management, require mandatory attendance procedures

2. List low attendance as a high impact and high probability risk in the risk register

3. Assign tasks to people not attending the meetings and see if they actually read the meeting notes

4. Give up on meetings for now, downshift into one-on-one interactions

Only when studying for the IIBA CBAP exam did she come to a decision. It came in the form of the first bullet listed item in in the IIBA BABOK (Business Analysis Body of Knowledge). This section falls into the Interviewing task description and that bullet list is focused upon the stated strengths of interviews. It says specifically, "Encourages participation by and establishes rapport with stakeholders."

Rapport sounds like a tremendous asset to her right now, not only for this project but all the ones she may be assigned downstream. She now had a direction to go in, she just needed to find a way to get around Mr. Middlebottom's constant interference and execute a strategy.

© 2017 Dwayne Wright

Stated Requirements vs. Actual Requirements

In the beginning of my business analysis career, I struggled a bit understanding the true difference between stated requirements and actual requirements. It seemed that the majority of conversations I heard at the time was along the theme of "that is JUST a stated requirement." It sounded like it was being treated as a second class citizen and its value shouldn't be given that much weight. While exploring a couple other pillar requirement topics, I gained a deeper understanding of stated requirements. 

From 2010, Bogie and I take a trip to Mount Dickerman on a fantasic day hike.

From 2010, Bogie and I take a trip to Mount Dickerman on a fantasic day hike.

In short, the difference can be about an evolutionary process. I realize that this might sound like a hot mess of a thought string but perhaps the point I’m trying to make will become more clear via the below narrative. 

One of the main components of active listening is paraphrasing what you hear in your own words. This technique allows a stated requirement the ability to evolve into a more defined state. This concept really takes form in situations such as: 

- stakeholder states a requirement
- the BA restates that requirement
- the stakeholder restates the BA restatement
- (wash-rinse-repeat as necessary) 

and finally a stated requirement has evolved to the point in which everyone has a shared understanding of its true nature and personality. 

Requirements, although they look amazing at the time, may not be actual requirements until they have been modeled. This is another transformation that is evolutionary in nature. The act of modeling the requirement(s) leads to a greater understanding and this process changes them from the original state to actual requirements to be baselined for project implementation. 


© 2017 Dwayne Wright

Three Good Subheadings To Put Into Your Elicitation Documentation Templates

Some days, all I want to do at work is fill holes in a project documentation template and listen to something catchy on my headphones. We have all been there and this practice can yield some amazing results. One of the predecessor steps in achieving that level of success is quality focused preparation of those templates. My opinion about template usage varies from positive to much less positive mostly on the motivation of the person that is going to use that template. 

My old buddy Bogie, always opent to the idea of taking some time to let me snap a fun photo!

If your approach is based upon finding the right template to provide aid in what you want to say, I have a super positive viewpoint. If you craft your own templates, can communicate to others your vision and it is accepted by them, I'm impressed. 

Lets take a slice out of the BABOK v3 and see how it might apply to a personalized business analysis template. According to the (all powerful and wise) BABOK, there are three common types of elicitation. These are collaborative, research and experiments. So the section of the template that covers the elicitation approach could look something like this:

COLLABORATION: <state situations in which elicitation will be accomplished with direct interaction with a stakeholder(s)>

RESEARCH: <state likely candidate resources in which you expect to find elicitation information for the endeavor and how you will leverage this information in your approach>

EXPERIMENTS: <state endeavors in which information or insights cannot be gained any other way than a prototype, proof of concept or other low level product creation method>

The following are three business analysis documents that could easily leverage value from such grouping your elicitation approach:

Approach documentation comes handy in situations where you have a large team of business analysts tackling a huge endeavor or when you have a junior business analyst that may lack elicitation experience. In both cases, you want to mitigate the risk of elicitation inefficiencies. Additionally, it is likely there will be a senior business analyst that will review and ultimately be responsible for the overall elicitation efforts. Being able to review information related to the three types of elicitation can be very appropriate here.

The word "charter" literally does not appear in the BABOK and this is a bit weird, when you reflect on how big of deal it is in the PMBOK. In most charters, there is a section to include requirements related information that may play a factor in an approval decision. Instead of putting "boilerplate" requirements here, you could include approach information. This can easily be valuable in obtaining the correct "go/no go" decision from leadership. 

The business requirements document or the requirements traceability matrix should have some form of traceability. It can be helpful to pencil in how requirements will be traced before you gather them. For example, you can add sections in a RTM spreadsheet for the three elicitation types and then fill in requirements right under those sections. 

So there you go, just another potential way to leverage classic BABOK content in the real world! Feel free to add your comments or email me your thoughts on this approach!

© 2017 Dwayne Wright

Estimation As An Elicitation Technique

In the BABOK v3 4.1.6, estimation is listed as a elicitation technique and I seemed to struggle with that concept initially. As I was staring at this line item, I thought that I might as well build a narrative to help fulfill my daily word count writing goal. So here goes ...  

This is from Sasquatch expresso stand and Zeke’s Drive In on Highway 2 in Washington state. A popular stopping place when doing all the amazing hikes in that area!

Estimation is one of the most flawed concepts in project management, particularly in software development. You have a better chance of bumping into “Big Foot” at the local Starbucks than find a project with a set of estimates that reflect what actually happens. Overall, you just need to assume that along the way you will loose ground on some tasks, gain ground on others and it will all work out in the end. If you have a project manager that is actually maintaining a project schedule, estimation could be a way to trigger a discussion about a task. It can be an indicator that an issue that needs to be resolved requires team attention. 

Regardless of how you feel about the cost-benefits of estimation, it seems to be a bit of a leap to include that as a method to "draw forth" requirements. I was prepared to write on and on about this anomaly until I remembered a time in which I used a planning poker session as a team building exercise. I could care less about what the estimates were that came out of that session. I just wanted to get a few silos in a room collaborating in a fun exercise and build a framework for ongoing shared understanding about the project requirements. 

I was stunned by how many hidden requirements came out of those sessions. As people began to defend their too low or too high estimates, all kinds of goodies came spilling out. Not just requirements, but also business rules, unidentified stakeholders, risks and a wealth of overall tacit knowledge.

So yeah, I’m onboard with elicitation being included as an effective elicitation technique. Still not a big fan of estimates though, just saying (grin)!

© 2017 Dwayne Wright