User Stories And The Structured Walkthrough

Although requirements documentation is important in a lot of areas, it is probably the most important as a communications facilitator. By its nature, the creation of a software product is essentially a communication problem. This is, in part, due to the fact that you're creating something fresh out of nothing more than a good idea. Another contributing factor is the diversity of individuals that will create the software product  and the diversity of the experiences they have to bring to the table. In many cases the conflict between these talented individuals creates a atmosphere where someone must win and someone must lose. This is more noticeable for teams that have just been formed and less noticeable for teams that have worked on projects together in the past. In almost all cases if one of the divisions of a software product completely dominates the other, the software product loses.

 Our little puppy Tanner, quite the bed tunneling expert!

Our little puppy Tanner, quite the bed tunneling expert!

In the most basic set up,  you will have a technical team and a business team on the project. It is common that the business team will try to exert what they consider are the technical elements on a project. This, of course, will start a natural conflict because the technical teams know more about technology than the business teams. The reverse is quite often true as well. The technical team may not see the sense of a business need and look to eliminate it from the technology implementation. In many cases, having teams work together on requirements documentation lowers these levels of conflict. If you have a requirements methodology that helps the business units focus mostly on the business communications and the technical folks communicating mostly on the technical implementation, you may have the beginnings of a healthy requirements phase. Here is one method that I have used with successfully in the past, that helps facilitate that type of arrangement.

Have your business units start the documentation ball rolling, a great place to start is defining user personas and scenarios. You may have to monitor business team members to ensure that they are not implementing technical recommendations within these narratives. However you do have to afford them a degree of flexibility, because they are actually trying to visualize a software product.

After you have these personas and scenarios defined, even if just at a high level, then a great addition to that is the user story. Although I think it is proper to have the business unit create the majority of the user stories, the game incredible value once the technical teams get to work with them as well. Much of this value comes in the fact that the technical teams do not know that much about the business, so they bring up questions and help fill in gaps that were created based upon the intimate knowledge the business unit may already have about a particular scenario. 

When the technical teams bring at these questions, you can see the business units begin to scratch their head and look at the issue in a new light. This is one of the values that you can have in a structured walk-through. I like the structured walk-through better then email exchanges in regards to clarify and user stories. Using email to clarifying user stories can be a timesaver however many times they just simply get the attention they deserve when done this way. 

It would be easy, although inaccurate, to say that you will have all your user stories validated in one structured walkthrough session. However the reality is that you will probably end up creating new personas, scenarios and even business rules during your first few passes. Although everyone on the team may want to groan when they come across something that simply isn’t good enough in one persons eyes, this is a good thing. It is better to get it correct now than have to rework the tasks associated with this “not quite right” requirement. 

Additionally, the overall process (although I admit can be tedious at times) facilitates a greater degree of communication between diverse project individuals. If all goes well, this entire process will become a bonding agent between the team members. You will find that you have longer enduring shared knowledge between the project team members and all the stakeholders that they may influence.

© 2018 Dwayne Wright

These Assumptions Must Be Identified And Clearly Understood

Some projects, both great and not so great, are launched based upon little more than a vague desire about reaching an idealized future state. The fact may be that leadership (or even just a single leader for that matter) has a vision of a future state and a whole bunch of assumptions. This project might be that vision, a component of that vision or just a stepping stone towards clarifying the vision. The thing is that leadership is moving forward because they have assumptions. 

 From a 2010 hike of Gothic Basin - Simply Inspiring!

From a 2010 hike of Gothic Basin - Simply Inspiring!

What the business analyst may need to focus upon (BEFORE ANY THING ELSE) is identifying those assumptions, understanding them, validating them, analyzing the results and then compiling them into a course of action. Not a course of action for the organization or even the project, the course of action for the downstream business analysis activities. 

As an experiment, I decided to GOOGLE the word assumption and see what was returned. Wow, I was taken back by what appeared to be subtle results but applied to the narrative I've already shared with you thus far.

1. a thing that is accepted as true or as certain to happen, without proof.
2. the action of taking or beginning to take power or responsibility.
3. the reception of the Virgin Mary bodily into heaven.

or translated for my (potentially lame) effort to make a point

1. An idea supported by things (not yet proven to be true)
2. Turned into related actions (via the power to do so)
3. To reach an idealized future environment


© 2017 Dwayne Wright

Documenting Constraints For Both Current And Future States

Constraints are aspects of a organization that hinder progress and many organizations don't really like to have the business analyst point them out. A natural thought process is that a constraint is something we should be able to fix and someone is to blame for them. This is often not true, many constraints are in place to serve purposes that may not seem apparent until they are removed. 

 A partially hidden constraint on my side of the bed.

A partially hidden constraint on my side of the bed.

The BABOK v3 has a nice little section ( about current and future constraints that may merit your review. Here you can see that there may be benefits for logging current constraints, future constraints, the constraints that were removed between the two and the ones that will continue to be in place. 

Exploration of the persistent constraints may have value to the business analyst because they are often associated with business rules. That may allow the business analyst to fulfill one of their highly under appreciated tasks for the organization. That is how a business analyst can often be a strong contributor to transforming tacit business knowledge into explicit knowledge that can then be leveraged by the entire organization.

© 2017 Dwayne Wright

How Business Analysis Work Will Be Approached And Prioritized


How important is it that the business analysis work be planned, communicated, documented and governed? Some may argue that the sheer number of unknowns about a business analysis effort requires more flexibility than process. Additionally, some may argue that a business analyst that follows a disciplined approach puts too much strain on the rest of the project team and leadership decision makers. Another popular argument comes from the agile world and the popular tidbit from the Agile manifesto stating "individuals and interactions over processes and tools."

Thoughts? Please feel free to email me at!

© 2017 Dwayne Wright

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