Tag: Best Practices

Use Case or User Story

Written by Steve Farrall on June 1, 2023. Posted in Articles.

An interesting question! Do we stick with use cases or switch to agile user stories as the best way to model, understand and deliver requirements?

The answer is to apply both techniques and together they work well to complement each other. In this approach, I view the use case as a business use case focused on business actions and processes; the user story is focused on the system requirements elaborating what is required of the system to support the business use case and supporting the agile sprint development process.

Use Cases

The objective of the use case in this context is to communicate the understanding of the requirement to the SMEs and stakeholders to ensure that the correct solution will be developed. It won’t be fool proof, but it should help steer the development in the right direction; until the first show and tell session, you can never be absolutely sure the requirement has been fully understood.

I would restrict the use case content to be only that essential to explain how the requirement will be delivered; alternate flows etc should be pushed into the use stories as far as possible. It may well be useful to expose some draft business rules for discussion as part of the use case but keep in mind the rules will need to be included and implemented via the user stories.

The Tool

We had already setup a wiki using the Atlassian Confluence tool, the logical step was to extend the existing wiki and introduce a fairly simple template for our use case pages; different tools could be adopted, even PowerPoint would work. Using Confluence allowed existing content to be linked directly into our use case pages as needed; it also includes a presentation mode allowing page content to be used directly in a presentation and exported to PDF or Word format documents.

The use cases can then be used to present back to the SMEs and stakeholders to confirm the understanding of requirements and the validity of the proposed process.

Tip – Catalogue Use Cases

It is useful to have index of all the use cases that includes a status to show work in progress, which ones have been published and those reviewed with SMEs. We managed our use case catalogue within Confluence using custom decision pages to provide an index view of all the cases.

User Stories

The key differentiator with the story is that it targets a specific system requirement and product feature, explaining a feature to an SME is a valid activity but without the context of the overall process, it might be a hard sell. Typically, you will need to introduce some supporting product features which may not be immediately obvious to SMEs; hence combining the stories together into a coherent business process will help SMEs to understand the overall solution context.

User stories can be identified but not elaborated depending on the level of confidence in understanding for a given requirement and business process. It may be appropriate to propose a change based on the understanding prior to a workshop or it might be better to get feedback from the workshop and then work on the stories with the knowledge gained.

The objective is to gain confidence in the understanding of a requirement so that everything can proceed down the right track with a joined-up set of product features.

Tip – Catalogue User Stories

A template for developing user stories can be adopted, this is useful as a prompt for details which may be appropriate e.g., what’s the existing feature doing currently and what needs to be changed. We managed our use story catalogue within Confluence using custom decision pages to provide and index view.

Joined Up Thinking

Use cases and user stories come together in the steps of a use case i.e., supporting the flow, whether it is worth elaborating main flows and alternate flows within a single business use case is debatable. The key objective is to keep the use case as simple as possible whilst demonstrating how the requirement will be met, so adding exception flows may cause confusion at this stage.

It is also possible that an existing feature will support a requirement without the need for a change story to be introduced; it is valid to include this feature in the use case as a step to demonstrate how this will work. For an existing feature, screen shots can be included and marked up with candidate changes; for a new feature then a wireframe mock-up may be included where a user interface is needed to support a step in the process.

Tip – Catalogue Use Cases

It will be useful to have index of all the use cases that includes a status to show which ones have been published and review with SMEs. We managed our use case catalogue within Confluence using custom decision pages to provide and index view.

Requirements and Use Cases

Now we are starting to build up a comprehensive set of product features that will meet the requirements and these will have been validated with SMEs; so, we are in a good position to elaborate the details of the user stories that will be needed to change existing features and add new features to the product.

Tip – Link Requirements

Linking requirements to use cases is a useful way to file the information, not all requirements will need separate use cases only those where confirmation is needed to better understand the underlying business need which can sometimes be obscured by a badly written requirement.

Conclusion

The use case is the glue that binds the product features and stories together into a comprehensive system that will meet the stated requirements; the user stories allow this requirement to be broken down into manageable features for delivery by agile sprint development teams.

Best of BATimes: 7 Warning Signs that You Are Too Soft

Written by Neal Whitten,PMP on May 17, 2023. Posted in Articles.

Simple question: Do you believe that you tend to be too soft at work?

What I mean by too soft is demonstrating behavior that results in being consistently less effective than what is otherwise possible—and needed—in performing responsibilities.

Whenever I ask this question at conferences, seminars or webinars, most people respond with a “yes.” From experience, I have found most project managers and business analysts, indeed, to be too soft—they are not willing to make the tough and unpopular project- or business analyst-related decisions, even though their instincts warn them that they are not taking the most effective action.

Being too soft harms your effectiveness, your career, the respect from others and your ability to make a difference and make things happen.

Examples of Too-Soft Behavior

Here are seven examples of too-soft behavior. Do you see yourself here? If so, this article may cause you to leave your comfort zone.

1. You behave as if you have the responsibility but without the authority

If you behave as if you have the responsibility but without the authority, then you’re too soft. I do face time with thousands of people each year. I frequently hear project managers and business analysts say that they have the responsibility but not the authority. This just isn’t true. You almost always have the authority; the problem is that you don’t take it.

Here’s an example. When was the last time you were called on the carpet—challenged—for exceeding your authority? Was it within the last week? The last month? The last year? Was it ever? My experience is that less than 15% of people in a large group—a statistically valid size group—have ever experienced being confronted for exceeding their authority. This is sad to me. But what is sadder is that, statistically, most people reading this article will never experience being called out on exceeding their authority across their entire career! My assertion is that you almost always have the authority—you just don’t seize it… you’re too soft.

2. You put off insisting on and driving good project management or business analyst practices

Whether I’m in a public setting or at a private company, it’s common for PMs or BAs to approach me for advice about their project problems. During the discussion, many times it’s relevant for me to ask about the project management or BA practices that they follow. I often hear them say that the practices they follow are weak and insufficient. They will state or imply that management in their organizations isn’t doing enough to provide and continuously improve the practices.

I’ll ask them what their role on the project is and they will tell me that they are the PM or a BA. If you are in either of these roles, then insisting on and driving good practices is your job. Not management’s. Not anybody else’s. It’s your domain of responsibility. You can seek help if you need to but the buck stops with you. If you do not insist on reasonable practices then you’re too soft.

3. You complain rather than constructively work issues to closure

I don’t believe that you should ever complain about anything—ever! Complaining is negative energy and adds no value to solving the issue at hand. People who complain are exhibiting too-soft behavior by averting truly getting the problem fixed. But make sure you understand what I mean by complaining. An example of complaining is when person A complains to person B about something that person C can fix. In this case, person A just wasted his time and person’s B’s time. However, if person A “complains” so-to-speak to person C—the person who can fix the problem—then this is not complaining to me. This is the first step of the solution by informing the person who can do something about it.

4. You evade taking a position on issues

If you evade taking a position on an issue, you’re too soft. A role of leaders is to help resolve conflict among team members. They take appropriate business-based positions on issues even if it doesn’t please all parties. Let’s look at an example.

I was mentoring Sarah who was a project manager of a sizeable project. We were walking through a hallway heading to a room where a meeting was soon to take place. We come upon two team leaders—Laura and Larry—discussing an issue in the hallway. Actually, discussing is too kind of description; they were angry at each other and loudly protesting the other’s views. Upon seeing this, Sarah leaned in to me and asked if I would mind if we join in on their discussion. Sarah said we have a few minutes before we must be in the meeting room. I said that that’s a good idea and we joined the two team leaders. After standing with the two team leaders and listening for a few minutes, Sarah turns to me and said we have to go; she did not want to be late for the meeting.

Once we were out of hearing range of the two team leaders, I asked Sarah why she didn’t say anything back there to help resolve the conflict. Sarah said if she had sided with one team leader then the other team leader would have been upset with her. I said that’s not how it works. Besides you now have both people upset with you because you did not assert your authority and help find an appropriate resolution. I went on to tell her if she sided with Laura and that left Larry upset with her, that’s not her problem—it’s Larry’s problem. I said never avoid taking a position because you fear that someone won’t like you. This is business, it’s not personal. Decisions are made based on what’s in the business’ best interest; not what’s in Larry’s best interest. Here again, Sarah was too soft in dealing with this situation which meant she was not as effective as she could be and should be.

5. You avoid or excessively delay making key decisions

Decision making is a critical action in any team, project or organization. We all have experienced instances where we felt decisions were being made far too slow. Make sure that you aren’t the problem. If you avoid or excessively delay making key decisions then this is another example of demonstrating too-soft behavior.

If you wait to make a decision until all data is known to ensure that you are making the very best decision, then you will lose all competitiveness. Better to make a decision and occasionally be wrong, then make no decision or excessively delay in making the decision.

6. You fail to perform your assignment as if you own the business

When you look around you for the people who you respect the most, they are likely folks who come to work each day with the mindset that they perform their duties as if they owned the business—and the business is defined by their domain of responsibility. If you have ever owned your own company, you will know exactly what I mean. You cannot put food in your belly or pay your bills unless you are successful. It’s this passion that helps people achieve their best. These are people who make things happen.

They believe—and their actions demonstrate—that the buck stops here and that they are fully accountable for the project or their assigned domain. Your boss and your senior management want you to take charge over your domain of responsibility with the passion that comes about when you behave as if you owned the business. If you hesitate or routinely pull back then, again, you are demonstrating too-soft behavior.

7. You require the personal approval of others to function

You are too soft if you personally require the approval of those around you to function from day-to-day—and without it you feel inadequate—then you will likely find their behavior to have an immobilizing effect on you; it can stop you in your tracks. Don’t ever give that kind of power to another person. What other people think of you should never be more important than what you think of yourself.

In Closing…

I have revealed seven examples of too-soft behavior. If you routinely exhibit these too-soft behaviors, then you’re clearly too soft—you tend to take the easy way out rather than do the right thing by demonstrating the most effective behavior. If you only occasionally slip into this behavior, then that may not be a serious cause for alarm.

If you fear that not being too soft will cause you to be “too hard” and therefore you will be seen as being rude, insensitive, abrasive, arrogant or a bully… don’t go there. You are a good and decent person and will not give way to these behaviors.

You might be asking yourself if an upside of demonstrating too-soft behavior is that you might win friends and respect? After all, if you are consistently too soft, those you work with will see you as very easy to get along with and passive—you’re always rolling over and abdicating to others. The problem is that if you’re a leader and are consistently demonstrating too-soft behavior, you will lose respect from those you lead, and from your peers and from your superiors. Being too soft will also have a negative effect on your project’s outcome because the best business decisions are not always made or made in a timely manner. All this can lead to your career becoming stagnant or even shortened.

Now, go become your imagined self!

Published on February 28, 2017.

Back To Basics: Excellent Elicitation

Written by Adrian Reed on May 11, 2023. Posted in Articles.

Elicitation is a core business analysis skill, and one that BAs typically utilize daily. It is easy to fall into the trap of thinking that elicitation is so basic that it doesn’t warrant talking about. Yet, just because it is a core skill doesn’t mean it’s easy, and it certainly doesn’t mean it’s unimportant. Not only this, but elicitation usually involves working with stakeholders, and whenever people are involved there can be inadvertent conflict and contradiction. Achieving clarity is rarely easy! In this article, I’ll address three perspectives of elicitation that you might find useful.

Elicitation As A “Trawling” Activity

In their book Mastering the Requirements Process, James and Suzanne Robertson use the metaphor of trawling to describe elicitation. The idea is, much like a fishing boat with a net trawls for fish, an analyst ‘trawls’ a business area for relevant pieces of information.

Ever since I first heard this metaphor I’ve liked it. Building on the Robertsons’ work and extending the metaphor, we might also say:

Where you trawl matters: If you trawl in an area with no fish, you’ll end up with an empty net. The same is true of requirements—ask the ‘wrong’ people and you’ll get very little.
The type of net matters: I’d imagine that the type and size of fish you are trying to catch will affect the type of net used. There’s a comparison here with elicitation—the techniques need to vary depending on the context and the types of requirements that you’re looking for. Detailed observation might yield very in-depth requirements, so might be considered a ‘small net’. A high-level conversation with an executive might yield high level outcomes and be considered a ‘big net’. Both are important, but it’s important to know which you are looking for.
There will always be stuff to throw back: Sometimes, it’s tempting to plan elicitation activity in a straightforward, linear way. As if you’ll be able to speak to person A, person B, do some observation and then everything is done. Of course, it never works exactly like that, as people will throw in curve-balls, there’ll be discussions which take you in unknown directions and so forth. I suppose this is a bit like trawling for fish: there will always be some fish to throw back if they are too small, too big, or the wrong type. In requirements terms, this shows that elicitation and analysis go hand in hand. As soon as elicitation starts, there will be filtering and prioritization happening.
Ethics should be built in to the process: I gather that fishing boats may throw back fish that are endangered, or are below a certain size. In terms of requirements, there is perhaps a lesson for us as analysts: If we come across a requirement that we believe is unethical, we should question it. This might sound like an odd thing to say, after all, who would raise an unethical requirement? Yet, with proposed technological transformation there might be an underrepresented group that is disproportionately affected, and perhaps this hadn’t been considered. It might be that the requirement owner had never considered the ethical consequences, and is very happy to amend or remove it once they think about the broader unintended consequences.

Elicitation Relies On Stakeholder Analysis

Much as elicitation and analysis are inextricably connected, there is a clear dependency on stakeholder analysis. Sometimes we might be led to believe that stakeholder analysis is a frivolous activity, after all, who has time to sit down and create stakeholder lists and models? Yet, the reality is that it’s one of those activities that will likely save time in the future.

I can still vividly remember a time, very early in my business analysis career, when I was assured that a particular project I was working on didn’t require compliance sign-off. I took this at face value, didn’t do any further stakeholder analysis and went ahead. Cutting a long story short, we got to testing and found that we absolutely did need compliance sign off. That was a scary revelation, but luckily our compliance colleagues were friendly and pragmatic. With some late nights and minor changes we got the project over the line. But for me, it was a lesson learned: Proper stakeholder analysis could have avoided it entirely.

I’m a particular fan of the stakeholder rainbow, and the stakeholder interest intensity index. I discussed a number of stakeholder techniques in a presentation that’s available on YouTube, feel free to check that out if you’d like to know more!

Context And Scope Matter

Finally, it’s worth noting that elicitation which doesn’t consider context and scope is really just a Santa’s wishlist. Imagine asking everyone in an organization “what is it you want?” or “what could save you time?”. You’ll get lots of ideas, many of them actionable, but you won’t get a coherent set of ideas.

This probably sounds so obvious, but it’s an easy trap to fall into. As analysts, it’s easy to be so familiar with the scope and context of a project that we assume everyone knows it. Yet that’s rarely the case, so spending a few moments to outline the core objectives and outcomes can really help.

This also highlights another key point: It’s absolutely crucial to understand the business objectives and outcomes being sought. Trying to elicit and prioritize without knowing the outcomes is virtually impossible. How can anyone say requirement A is in scope (or not), and whether it’s more important than requirement B if there’s no clear agreement over the ultimate outcomes being sought?

Conclusion: Shine The Light On Elicitation

It’s easy, particularly as an experienced practitioner, to let elicitation become second nature. That is completely natural. But perhaps it is worth spending time now and again reflecting on how we elicit and whether it is still effective. Although it might not be a headline-grabbing topic, elicitation is absolutely crucial to what we all do!

Best of BATimes: The 7 Habits of Highly Effective BAs

Written by Priyanka Agrawal on April 26, 2023. Posted in Articles.

In my experience as a Business Analyst (BA), I have seen many analysts struggle in trying to strike the right levels of analysis. Some analysts tend to overanalyze while others, under analyze. Getting trapped in the dilemma of when to stop and/or when to continue analyzing can put you into a vicious cycle of ineffectiveness and devaluation. The result: zero business outcome yet a ton of frustration and a huge load of wasted time and effort.

The 7 habits of highly effective BAs guide you in establishing thresholds and protocols for your analysis finish line and helps you determine how far you are from the finish line. These 7 habits provide you with a compass that guides you to determine when to hit the breaks and/or when to accelerate your analysis.

1. Be cognizant of the allotted project budget and schedules. Create a mini work breakdown structure (WBS) for yourself that distributes analysis tasks and activities based on the allotted time and effort. Over time, you won’t need to formally put this down on paper and your mind will automatically signal you when you’ve exceeded or unfulfilled the allotments. However, be aware that this strategy alone may not help you in striking the perfect level of analysis. For best results, combine this technique with one or more strategies described below. For example, requirements analysis can be about 25-30% of an overall development project. If the analysis is taking more time than testing and programming put together, there is something evidently wrong. The flaw with this approach is that you will need to continuously monitor your project spend before you determine you’re on the wrong track which sometimes can be too late in the game to backtrack.

2. Establish and communicate success criteria at the onset to understand where the real finish line is. Once you have fulfilled the success criterion, you’ll know that you’ve more or less completed the required level of analysis.

3. When performing use case analysis, ensure you’ve considered not only normal and alternate flows but also exception flows. In my experience, at least 1 normal flow, 2-3 alternate flows, and 0-1 exception flows are typically enough.

4. Ensure you understand the inputs (preconditions), outputs (outcomes and postconditions), and actors before you start your analysis. This will help you say focused and on the right track in terms of scope.

5. Always refer back to the business objectives, goals, and vision. When performing any sub-activity, always ask yourself if what you are doing is related to, impacts or is impacted by the overarching goals. If the answer is no, stop! If the answer is yes, continue and go back to the success criterion.

6. Define limitations, assumptions, and constraints and keep those in mind all along when performing analysis. This will help you rule out some scenarios and help you continue on your journey to a fruitful analytical activity.

7. Know your audience. Ask yourself these questions: Who is the receiver of my analysis? Who would my work interest? Knowing who you are performing the analysis for will help you identify the level of detail required and therefore the amount of analysis to perform.

Read All About It – Why Reading is a Critical Skill in BA

Written by Jake Thompson on April 20, 2023. Posted in Articles.

I love reading.

It is to the point of compulsion where I log into my Amazon.com account and sneak in a couple titles
of varying degrees, regardless of what my original intention was. I always mutter a friendly curse
towards the algorithms that market new, old, debut and longstanding authors of novels, novella, and
fantastical stories each time I log in. It is not just limited to online…oh, no, not at all. Traveling, locally,
domestic, or internationally? Same problem. I make it a significant point to dop into any local
bookstore with self-guaranty that I will walk out with, at minimum, one book, genre notwithstanding.

Reading, however, has become so much more than just “getting lost in the story” or falling in love with
characters whom we can only dream to meet, mirror ourselves against or become attached to. It is not
a hobby, it is not just a compulsion, it is not habit. It is something else, something more: a skill. A
critical skill, at that. A skill that, like anything, any one can become proficient, an expert on, but
requires the same thing: practice, practice, practice. While I could spend the time writing this piece on
the top ten books a business analyst should read (and was the original idea for this article) …instead, I
make a proclamation. A quasi-Magna Carta, if you would: all business analysts must take the time in
their schedules to make room for improving this critical and formidable skill.

Today, there are rumors of studies finding that young adults after their high school (post-secondary)
education will never read a book again. It is flabbergasting on one hand, but to lose a critical skill like
reading that is sharpened when you open the cover-to-cover bound print matter (or e-book for you
digital readers), it is breathtaking. We, as business analysts, whether we realize it or not, are
consistently reading. Reading our e-mails, reading our business analyst documentation, reading
requirements. You are reading right now, are you not? That is pending that you continue to read my
piece on this subject matter. We are, in and out of varying intervals and degrees, reading! Some read
faster than others, some take the time to deeply understand and analyze what is on the paper, or page
before us. Aside from this, you are inherently practicing a critical skill in which will only make you
better, as a business analyst.

Google search any reason as to why human beings should read and the results are countless: whether
it be for stress relief, for better memory retention, to prevent disease, it is all relevant. However,
relevancy aside, it becomes relevant to our work. Reading requires us to think, to analyze, to ask
ourselves questions. Is that not what we do now? Think, analyze, ask questions? Of course, overlooking
that I am oversimplifying the business analysis method, reading leads us to business analyzing!

Reading only stands to benefit you to improve in these areas; reading helps establish connections, to
understand concepts. Who does not like conversing in the language of titles, authors and favorite quotes
from that series or book that came out last week, month, year? There once was a video game I played
as a young adult and in the conversation of movies, they spoke about how movies during their time
(when movies/cinema were in their Golden Age), help people out of a bind or jam that they do not
understand. Take out movies/cinema and replace with books/reading, and there you got it.

So, read all about it! And I do not mean that slogan about the latest newspaper (although a reliable
source for information), I truly mean…read all about it. Being able to become a fount of knowledge
and to be able to translate that knowledge into performance as a BA should be your guiding light. As
a business analyst: think about it, analyze it, ask questions about it. Understand it…you will thank
yourself someday