Tag: Use Cases

Are You Suffering from Agile Fever?

Written by David Shaffer on November 15, 2017. Posted in Articles. 1 Comment on Are You Suffering from Agile Fever?

Have you ever come across a colleague or a family member who has a knack for making every conversation about them?

Do you have people in your social circle who influence every group decision to their benefit? Of course you do! When describing these people we typically say “You know the whole world revolves around Joe!” Do we really enjoy spending time with these people? Of course we don’t because they are exhausting and frustrating to work with. Well let me tell you something, these people have a lot in common with user stories. The user story has become the center of the Agile world. Everything in Agile seems to revolve around the user story. They have become exhausting and frustrating to work with for many of us. How did we allow this to happen? How did the Agile community get to choose the technique we must use to convey the requirements for a solution? The BABOK details numerous techniques that BA’s can master for the purpose of eliciting business needs, determining “wants” from true “needs” and communicating the actual requirements which must be met. Why is the user story being elevated in importance over all other techniques? I have personal experience in “Agile” organizations who are absolutely obsessed with the user story. I’ve also been fortunate enough to meet many of my BA colleagues at conferences who have the same frustration. Why do we seem to be limiting ourselves or over relying on this one technique?

Mike Cohn of Mountain Goat Software is regularly credited with coming up with the format of a user story. I’m sure we’re all familiar by now with the “As a _____, I want to _____ so that I can _____.” format. By no means do I intend to discredit this format or this technique. It can be valuable in the right situation.

However I view the user story as a singular tool within our BA tool belt. One single tool should not be the center of any development methodology. Unfortunately I’ve come across some development colleagues who are infected with Agile fever. Agile fever causes the temporary loss of common sense and logic and is characterized by an irresistible desire to adhere to an irrationally dogmatic process. Those infected with Agile fever latched onto the user story as the center of their world since it seemed to have lots of potential. It has a simple format and it seems that anyone can write them. With the user story as the center of the universe time consuming business analysis could be eliminated and replaced with simple user stories and conversation! What a eureka moment this must have been in the Agile community. I can imagine the crazy celebrations which must have ensued. As many of us are learning this is not necessarily working out as planned. Some organizations that tried to eliminate BA’s or relied entirely on the conversation generated from user stories learned that Agile fever can have serious consequences to their business.

So what does Agile fever look like and how can you tell if your team may be infected? Let me give you some examples. A developer once explained to me that he understood the requirements and knew exactly what we were doing and why. However he demanded that the requirements be reworded into the typical user story format because our group was “Agile”. Agile fever was infecting him to the point that he could not function unless the user story became the center of his world. Once the requirements were rewritten he instantly calmed down and was able to function once again! If project team members are demanding requirement rework so you can be “Agile” then you’re likely infected. Agile fever can also cause Goldilocks paralysis. If you’re not familiar with Goldilocks it is the story about a little girl who wanders into a home occupied by three bears. While in the house she tries out three chairs exclaiming “This chair is too big! This chair is too small! And this chair is just right!” I must warn you that Goldilocks paralysis is extremely contagious and can infect entire project teams very quickly. It is characterized by project teams that spend significant time arguing over the size of the user story. You’ll hear comments such as “That story is too big! That story is too small! “We need to break these stories down” or “This story doesn’t fit in our sprint”. As a BA if you notice teams arguing over the size of a story and wasting significant time over it then be aware that they are infected with Goldilocks paralysis. It is treatable with an injection of common sense and reason but it may take a while to take effect depending on how high their Agile fever is.

So what do I suggest we do as BA’s to counteract this over reliance on the user story? I propose that we remember that the word “analysis” is in our job title. Therefore we must never forget that great analysis is what our methodology should revolve around not a single technique. Don’t let anyone influence you away from using other techniques. Great BA’s utilize the right tool or the right technique at the right time to uncover the business needs that will drive business value. The user story is one way to convey that information but it does not need to strictly adhere to the standard format. I have successfully used fully dressed use cases (Oh my!) on a project since they happened to be the best way to convey the requirements for that particular project. Don’t be afraid to think differently and convey the requirements in what may seem to be an unconventional way because it doesn’t fit into the Agile prescription. Drawing a picture, creating a wireframe or using some other visual technique will drive conversation much better than a standard user story. Do some stakeholder analysis to make sure all possible stakeholders are being considered. Then go ask those stakeholders to tell you stories related to the problem that must be solved. Trust me you will have richer conversations and uncover information that the traditional user story would not. My fundamental point is that we as BA’s are software professionals that have creative analytical skills that must not be suppressed by an over reliance on any one technique. So wash your hands, clean your keyboards and get enough sleep so you can avoid Agile fever. If the BA becomes infected then the project team is certainly doomed!

Data Science: Critical role of a Business Analyst

Written by Suraj Chatrath on October 19, 2017. Posted in Articles.

The last decade has witnessed a sudden spurt in vast amount of data, which enterprises possess, on their customers.

This data is generated from disparate sources like social media, mobile, applications, financial transactions, e-commerce, search and Internet of Things etc. According to an IDC estimate, from 2005 to 2020, the digital universe will grow by a factor of 300, from 130 exabytes to 40,000 exabytes, or 40 trillion gigabytes. From now until 2020, the digital universe will about double every two years. Further, IDC estimates that only a tiny fraction of the digital universe has been explored for analytic value. By 2020, as much as 33% of the digital universe will contain information that might be valuable if analyzed.

Previously, companies were able to analyze relatively smaller set of data through various data mining techniques and tools. However, with the data exploding from multiple sources, data science as a field is quickly emerging. Data science refers to interdisciplinary field about scientific methods, processes, and systems to extract knowledge or insights from data in various forms, structured or unstructured, similar to data mining. The key highlight of the definition is “insights” as it means generating findings which are previously not known from traditional data mining techniques or simple trend and regression analysis. That is why data science as a field is considered to be at an intersection of mathematics, statistics, software and business domain knowledge. One of the simplest examples of usage of data science for any company is its ability to predict customer churn in advance. It can help the company to work on the customer retention instead of focusing only on costlier customer acquisition.

While there are various tools available in the market for data science, but a very critical part for success of any data science initiative is defining the use cases from business standpoint. In most companies, technology teams are adept at understanding the data and running analysis over them. However, field of data science in unique in a way as the teams can sometimes not know what they are looking for in the data as the insights may mostly not be a established fact. Hence the role of business analyst becomes so critical in this field as you would need a person who is fluent not only in the IT domain but also speak in the language of business leaders.

For example, data science business analyst would be expected to convert the business problem statement “Given past performance and current trends, what is the likely outcome of a certain action” to an IT problem statement which means what data needs to be analyzed to arrive at the insights. The data would then be reviewed with the technology team and results would be delivered to the business team in form of insights and data patterns. Business analyst should also be knowledgeable enough to apply various predictive modeling techniques and right model selection for generating insights for the problem at hand.

One would argue, what’s the difference between a business analyst in data science domain compared to a general business analyst. One of the key skills, which differentiate the data science business analyst, is its deep understanding of data as well as industry and functional expertise, which would enable him/her to understand the business context and identify the use case. Data science business analyst is required to have deep business knowledge and understanding of data as depth and breadth of data increases. Further, business analyst would also have to work alongside with business and technical teams and should be comfortable speaking in their language. Mckinsey in its report on “The age of analytics” mentions that while data scientist is a critical skill, companies need “translator” who serves as the link between analytical talent and practical applications to business questions. Mckinsey also highlights that first of the five critical elements for establishing successful data and analytics transformation require use cases which are also defined as source of value. The uses cases should clearly articulate the business need and projected impact.

Another key role of the business analyst for data science assignments is to identify the “optimal” model for the data based use case at hand. The business analyst should possess the knowledge to frame the right hypothesis to test it. Albert Einstein once said, “If I were given one hour to save the world, I would spend 59 minutes defining the problem and one minute solving it.” In simple terms, business analyst puts a framework to the problem solving process. Business Analyst should be able to answer questions like:

“What is clustering or regression and when should I use these techniques?”
“How do I formulate a hypothesis on my data?”

Most companies are not able to realize the true potential from data science assignments as they rely heavily on data scientists who are very proficient at data preparation, cleaning and modeling or writing software code via tools like python, R but lack the domain knowledge and meaning of data in business context. This is where the business analyst plays a very crucial role of bridging the divide between the business teams and IT department for complex data science assignments.

The Use Case and I – My 10-Year Journey

Written by Michelle Green on July 5, 2017. Posted in Articles.

I’ve been a BA for nineteen years, and it wasn’t until about ten years ago that I met my first Use Case.

Since then I’ve used use cases in different ways for different types of project efforts. I’ve used them for:

As stand-alone requirements
As a supplement to stakeholder requirements
As a vision and scope communication tool
As functional requirements

In this article, I’ll be taking you through my journey with Use Cases in the hope that you might gain a better understanding of what use cases can do for you. I’m not saying that any of these approaches is right for everyone or even work all the time, but learning is an evolution. I live by the Brian Tracy quote, “You can only grow if you’re willing to feel awkward and uncomfortable when you try something new.”

Stand Alone Requirements

Ten years ago, we were picking up a new automated workflow system to replace an outdated product. An independent consultant was brought in to help our newly formed Business Process Office (BPO) determine some standards and processes they wanted to use within their organization. The objective was to learn how to identify, document, and select business processes that were good candidates for automation. I was brought in to learn the new processes and help identify ways that the company’s Business Analysts and the new BPO Subject Matter Experts (SME) could work together with the system developers as one team. One of the tools the consultant recommended to capture workflow automation requirements was a Use Case Specification Document, including, among other things the Use Case Diagram and Use Case Narrative.

It was an “Ah-Ha” Moment. I had never used use cases before, but I could tell right away that it was going to be the start of a beautiful friendship! I had finally found something that the business and the technical team could both relate to while representing the voice of the customer.

During the next couple years, we used a Use Case Specification Document as our sole requirements document for all things “automated workflow.” In hindsight, this approach only worked well because we were developing workflow automation. Business SMEs were the workflow designers, business analysts were working with them during use case development, and the technical resources were active team members for the entirety of the project. We weren’t working within an agile framework, but the co-located team principal and light documentation concept applied.

Supplement to Stakeholder Requirements

Flash forward a couple of years. The BPO had grown and was now engaged in most business projects that involved workflow enhancements. They were comfortable with use cases, but we had a project where use cases alone weren’t enough. We agreed to attach the use cases to the Business Requirements Document (BRD) and trace to them in the stakeholder requirements. Functional requirements were then written and traced back to the Stakeholder requirements.

During System Integration Testing we noticed some inconsistencies in expectations. What we found was that although many of the stakeholder requirements traced back to the use cases, the programmers were concentrating on delivering on the functional requirements, ignoring the higher-level detail. They had only looked at the use cases the first time they reviewed the Business Requirements Document (BRD) and didn’t follow the traceability all the way through. They considered them as a guide rather than an expectation. There was not cohesive understanding of the purpose of the use case.

Here’s the lesson we learned: If I could do that project over again, I would have included the use cases in the functional requirements and highlighted the purpose they provide.

Vision and Scope Communication Tool

I was paired with a Project Manager (PM) and Solutions Architect (SA) to work with a business unit to determine a high-level scope of a project for making a buy versus build decision. The goal was to replace an existing user interface system with one that could handle more complex business rules. We were on a tight deadline and every day counted.

In the first Joint Application Development (JAD) session it became obvious the business had a very clear vision for the system capabilities. It was also evident that the architect did not fully understand the scope of the request to determine what technology should be considered. We only had days to present options and t-shirt sizes to our sponsor. I needed to quickly achieve a joint understanding of the vision and scope and communicate it effectively to both the business team and the solutions architect.

Then it hit me. I could create a vision use case. Writing the use case at a high-level, I was able to insert existing system interfaces (which could potentially be re-used), show exceptions, and get a business agreement that the use case met their expectations for the new system. I took the use case to the architect, and we walked through it. With his previous architecture experience, he leveraged the use cases to draft different context diagrams highlighting interfaces for each of the build/buy solutions. The two items together allowed the business to make a quick decision, and the documents became our scope and outline to fund our detailed requirements.

Moral of this story was that in the right landscape, you could utilize use cases to communicate vision, define scope, and by the time you’re done have a great high-level requirements document,

Functional Requirements

With use cases there tends to be two different schools of thought: 1) Functional requirements are written to support use cases, and 2) Use cases are functional requirements. For this last project, and most of my projects after that, I have been leveraging use cases as functional requirements.

I was assigned the task of eliciting requirements for implementing custom packages for a Commercial Off-The-Shelf (COTS) system. In the BRD there were plenty of standard functional “The system shall…” requirements for pieces of functionality, but where a workflow was involved, use cases were embedded with the functional requirements.

Example:

In later projects, I have been known to add another section in the functional requirements for Use Cases as stand-alone components.

Conclusion

I have read different articles where experts recommend placement of use cases in requirements documents, but I like to go with the principal that the best direction to take is whatever gets you to a place of joint understanding before your audience. Learn all you can about how to use the tools in your BA Toolbox, then experiment with how to use them for your audience, as I did with my friend the Use Case.