Tag: Elicitation

Mobile Business Analysis Toolkit

Written by Veronique Manuel on February 13, 2018. Posted in Articles. 1 Comment on Mobile Business Analysis Toolkit

Several years ago I was leading a team of agile business analysts on a journey to document user stories (requirements) for a new mobile app supporting one of the largest business functions at our company.

We have an existing web application with tons of features, and the stakeholders love it. Our biggest challenge was figuring out how to take the features of the web app and downsize them to mobile. The answer was simple – DO NOT take all the features in the web and put them in mobile! The primary differentiators for mobile are identifying the user personas, the types of users who will use the app and define the use cases, the specific scenarios or actions the users will perform.

The Mobile Business Analysis Reference Guide includes ‘tips’ and ‘things to consider’ for mobile initiatives. These tips can be added to your virtual BA toolkit. The BA toolkit includes the tools, processes, and templates needed for day to day business analysis efforts. This can include anything from word and visio to more formal requirement management tools. Your organization may have custom tools or processes as well.

How is Mobile Analysis Different?

Mobile apps typically serve three distinct purposes – Enable, Support & Leverage. Mobile is not simply a miniaturization of a web app. If a web app exists, mobile may be viewed as an enabler. Mobile apps support mobile users, those that go to the app for a specific purpose for a limited amount of time. We can also leverage the technology offerings of mobile. For example, many apps leverage features such as location services, notifications, and camera. The functional and non-functional requirements defined during analysis are inputs to the solution design recommendations for mobile.

The following reference guide highlights questions and ‘things to consider’ for mobile apps. Add the reference guide to your virtual toolkit and pull it out when you find yourself on a mobile project.

Mobile BA Reference Guide

What functionality should be included in the mobile app? Does a web application exist? If so, determine the selected functionality suitable for the mobile app.
- Mobile applications have primary targets in terms of functionality. If a web app exists and a mobile version is being developed, determine the primary features that need to be included in the app.
Should the app be built for tablets and smartphones? What are the primary differentiators?
- All apps are not built for both tablets and smartphones. Determine the user personas for the app. Are they phone users or tablet users?
- Is the content optimized for smaller screens? Text-heavy solutions may be best suited for tablets.
- What are the primary use cases for the app? These questions will assist you in determining and/or recommending the type of mobile devices for the app.
UI/ UX considerations such as screen size, transitions, non-functional usability considerations, orientation, transitions

How to connect security standards/ guidelines at your organization to ensure security standards are followed? Consider the following:
- Authentication
- Authorization
- Network Requirements
- Device Security
- App Restrictions
- App Interactions
- Network Access
- Data Security
Mobile users are…mobile. Mobile apps have unique scenarios that should be considered for various conditions. Note: There are architecture, design, and UI implications for each scenario. Collaborate with your team to determine the best approach for the project.
How should the app respond to each contextual scenario below? What happens to the data when the user is…
- In a cab and lose app connection?
- On a plane traveling and airplane mode is enabled?
- On a train and data connection is interrupted?
- Using the app and receives a phone call?
- Using the app and receives a text message?
- Using the app and other app notifications appear?
- Storage low; no storage?
- Battery low; battery dead?
Given the different functionalities, one app or multiple apps?
- If multiple apps, how do you decide a breaking point with a ‘user-friendly’ cross-app navigation?
How do we utilize the technological advantages the smartphones/tablets provide to improve the experience? Identify native device functionality vs. app functionality. Examples include:
- Geo-location services (GPS Functionality), Accelerometer (games, pedometers, maps, etc.), Hardware keys (camera, media players using volume, hardware buttons to snooze reminders, etc.)
What relevant notifications are needed for the app?
- Push notifications – notifications on device; does not require user to be logged into the mobile app
- Example: New article or activity published, user is informed via notification on device screen; does not have to be logged in
How will data be presented in the app?
Should screens retain user input if the user navigates away from the screen? The app will need to implement periodic auto-saving, state management, or possibly navigational considerations

What About the Current State?

Written by Esther Medina on January 18, 2018. Posted in Articles.

What about it? It’s an old, slow process, barely working and will be replaced soon with a new fully automated, high-tech solution.

No one needs it and the sooner we’re rid of it, the better it will be!

In this age of innovation, when everyone is being encouraged to look into improving and streamlining current processes, we suddenly find that the methods that served us well all these years are being looked at as antiquated and more than ready for a refresh. Sure, we are all for finding ways to do our jobs more quickly, with fewer keystrokes (maybe even none) in less time. So let’s hurry and build this nice new solution. Why bother about what we have now? Why do we have to look at the current state?

Because it is part of the key to a bright future state.

“One must first understand a process before one can change it, much less, improve it.” I don’t remember when or where I read this, but the message has stuck with me since. How simple, how elegant, how true! Yet in our excitement to better the world, we often overlook this important step.

Taking time to understand the (most probably) clunky current state from start to finish enables us to 1) examine each feature to determine why it may or may not be important to include in the new solution; and 2) establish a baseline against which we can measure the success or shortcomings of the future state or its prototypes.

When looking at an existing system process, for example, we can note features that are available but not widely used – why is that? Would users take advantage of it if it were more visible on the screen? Or maybe the conditions for its use do not come up often and therefore, may justify exclusion from the new solution? We can consider additional steps done elsewhere but are required to complete this process – for example, a rate that needs to be looked up on another system before it is entered on screen. Would it be possible to get the rates fed automatically into the new solution or should this process be done outside of the new solution, but as part of some other more appropriate process? We can ask the users what they like most about the system, find the reasons why and ensure that this functionality is not lost when we plan for a new solution. In the end, we may find that a new solution is not required; the current state will do nicely with just a few tweaks. Or we may come to the conclusion that nothing works properly with the current state, and therefore, everything will have to be built new. Either way, the knowledge acquired at the end of this analysis will serve as a blue print of what the future needs to look like.

Once the new solution is built, this blue print will also serve as one of the guidelines on what and how we should test the new solution. How was it working before? Should it work the same or differently in the new world? Should the end result be the same or different? Does the new process take more or less time than the old? Does it involve more or less manual effort? Hopefully, it will be all the current process is supposed (or not supposed) to be.

Following are some techniques we can use in our current state analysis:

Data/Process/Interface Modelling and Analysis – understanding current data structures and the processes (including interactions with external processes) that use them may uncover opportunities to improve data integrity and streamline future processing.
Business Rules Analysis – understanding the rules that may have defined and/or constrained the current state design may give insight as to which of these will impact future state design.
Document Analysis – reviewing existing documents may uncover information towards understanding of the current state.
Interviews/Surveys or Questionnaire – getting first hand feedback from end users may identify unspoken requirements and opportunities for improvement.
Observation – witnessing first hand actual processing and usage may identify opportunities for improving the user experience.
Data Mining – identifying patterns related to usage of our current process/product/service may enable us to use these patterns to our advantage.
Benchmarking and Market Analysis – comparisons against industry and market standards may identify opportunities to make our process/product/service stand out within the industry and measure up to consumer expectations.

Each of the above techniques gives us a clear view of what currently exists and at the same time, allows us to make plans for the future, giving us a rose-coloured peek into what may be if we can only get the right people, sufficient funding and enough time to work on the new solution. But that’s for another article!

Bottom line, investing time to understand the current state is a crucial step to get to your desired future.

Planning Workshops Using the 7Ps Technique

Written by Ryan Hewitt on January 2, 2018. Posted in Articles.

It’s difficult to plan for a workshop. There’s so many things to consider, sometimes it’s hard to know where to begin!

The best technique I’ve used for planning workshops is called the 7Ps. I found it in an excellent book called “Gamestorming”.

I use the 7Ps to create a clear agenda & make sure I’m prepared for a workshop.

How’s it work?

The technique asks you to consider the following areas for planning a workshop:

Purpose – why are you having this session? I tend to write 3-4 bullet points to summarise the purpose. This is the most important question & worth starting with
Product – what artifacts do we want to come away with from the workshop? You can think about this as outcomes or deliverables
Process – what will the agenda be? This should tie back to the purpose. The process needs to ensure you achieve the purpose & come away with the products you want
People – who will be in the session? And equally important – what role will they play? What kind of questions will they be there to answer? Will one person represent the technical side of the business. Will one person be there to sign-off the scope?
Pitfalls – what are the risks of the meeting? E.g. a particular question that might blind side you, that some people will want to delve into detail. Think about these pitfalls & write down how you’ll mitigate them
Preparation – what do you need to in advance of the session? E.g. do you need to create a presentation deck. Do you need to bring information to the meeting?
Practical Concerns – these are things around logistics. Where’s the meeting? Do you have a TV? Who will meet the visitors etc

Working example

Below is an example of how I recently used the 7Ps.

I was planning for a workshop with a new vendor. We wanted an all day session to convey our initial requirements & allow the vendor to feedback on what they could deliver in their first release. It was also our kick-off session for agreeing how we’d work together on delivering a service.

I sketched out the below 7Ps and sent it to our team for internal feedback.

Purpose – 3-4 bullet points felt like the right level of detail. The above purpose was what I wanted to get from the meeting; however I also considered what others / the vendor would want to get out of
it. It’s always worth thinking about other people’s expectations. I start on this section first – because that drives everything else
Product – I find this to be the hardest section. In this example the product was a collective agreement of scope & how the scope would be delivered. The product was a NOW/NEXT/LATER roadmap which would be updated in the session. Sometimes the product isn’t tangible (e.g. getting everyone to understand why you’re making a change)
Process – this was the next section I filled in. After identifying the purpose & product, I thought about what an agenda might look like / a typical running order. Each item here contributes to the purpose – and ensures we come away with the right products. Tieing the process back the above ensures that agenda items are necessary and add value
People – this is always really useful. Sessions shouldn’t have more than 10 people. It’s useful to think about who needs to there – and what their role with be. A role might be: to answer technical questions, to represent the product team, to answer any questions around operations, or it can be a job title
Pitfalls – I try to think about likely pitfalls. For our session, it was that that we would be drawn into the detail, and that we’d be asked a specific process question which we didn’t know the answer to. We actually invited the SME to mititgate that pitfall. And we created a question board where very specific questions could be parked
Preparation – who will create the assets before the workshop? What will they create & bring? I put names & deliverables in this section for our workshop
Practical Concerns – these are often things that people forget about. For our meeting it was: booking people onsite with security, checking the room has a TV, booking a room all day so that we could setup ahead of time. This became a checklist to make sure we were ready to run the workshop

Summary

I find the 7Ps a really good technique for conducting focussed workshops.

I typically use the 7Ps on my own to create an agenda, then take a picture and get people’s thoughts. This way attendees can feedback on the agenda. I find the “Process” & “People” sections are particuarly valuable for getting feedback & co-designing an agenda.

I find creating a physical version of the 7Ps means I can cross things out & move between sections easily. I often move from one section to another – and back again – as its all interconnected.

Hopefully you found this article interesting. And it’s a technique you would consider when planning for large workshops 

Business Analysts Embrace Non-Functional Requirements

Written by Rohela Raouf on December 26, 2017. Posted in Articles.

It is often argued that business analysts like functional requirements, so, therefore, they tend to naturally gravitate towards these.

On the other hand, the humble non-functional requirements are left in the shadow and rarely given a second thought until the last minute. Doing, this causes many issues when you are about to go live with a system. While the system/product may look great, if the performance is not there then no one will use it. This will impact the business a lot more than if a nice to have a feature is not included in the final product.

Differences

Functional requirements fall into ‘WHAT’ the product is trying to do while the non-functional requirement falls into ‘HOW’ it is going to do it. So, it is naturally understandable why BAs like to focus on functional requirements- you can show the users, customers, and managers what the product is going to be doing. It is a lot more difficult to get the managers or the customers excited about non-functional requirements.

Coffee cup

While it can be argued that non-functional requirements are not glamorous as functional requirements. I am just not sure really why non-functional requirements are left to the last minute. When I purchase a takeaway coffee, I want the company who created the container to have paid the same amount of attention to how it was going to be transported as well what is going to be in the container. Let’s, take this further I regularly access BBC website, the reason I use this product is not only because of the content but also how well it performs i.e. how quickly the pages load.

Twitter fail whale

There have been many high-profile cases where the business has not paid full attention to non-functional requirements. You will frequently hear about how a website has crashed because the business had not fully anticipated the capacity required. If you used Twitter in its early day you would have come across this whale, when Twitter was over capacity and therefore was unable to handle the demand. This naturally caused a high level of frustration of the service and they were very vocal about their unhappiness. Twitter fail whale is a great example of what happens when the business does not forecast correctly the level of capacity or understand the scalability of its product.

Key things to look for :

If you are new to non-functional requirements, the following are different areas of non-functional requirements that you need to look at when you are eliciting these requirements.

Performance: What should system response times be, as measured from any point, under what circumstances?
Volumetric: what is the volume of users that are going to be accessing the system?
Scalability: what is the peak transaction volume? Peak user levels?
Capacity: what is the volume of users that are going to be accessing the system?
Availability: what are the hours and days that the system is going to be available?
Reliability: what reliability (excluding planned outages) is needed?
Maintainability: how is the system going to be maintained? Who is responsible for the maintenance
Security: how is the system going to be protected from hacking? What will happen if it does get hacked
Auditing: how long do you need to retain the data? Do you need to who is accessing the system and what they are accessing?
Recoverability: what is the disaster recovery policy if the system goes down?

There are other non-functional requirements that I have not stated above that you may want to look at; Interoperability, regulatory, serviceability, usability

Eliciting non-functional requirements

Eliciting non-functional requirements is not easy as asking the business what do you think are the ‘maintainability requirements’. You will need to speak to other members of the project team, for example, the technical architect should be able to help you with most of these requirements.

If you do not or unable to speak to technical architect then speak to the end users of the system to get a baseline to what is current ‘As is’ situation. By getting a baseline you will be able to categorise the information. For example, a sale assistant has bring up a sale order screen when talking to customer

Objective: what is the objective behind this scenario
Process requirement: retrieve customer details
Non-functional requirement: how quickly should the screen load

By categorizing the information in the above manner, it allows you to analyze and assess whether there is a need for a requirement and what the priority is this for the requirement.

It is important when you are looking at non-functional requirements that you do not elicit them in isolation.

Documenting

Dependent on the type of the project methodology that you are using will depend on the artifact that you are going to use for documents. For waterfall projects, you will use requirement catalogue to document the non-functional requirements. In Agile, you should document them on the back of a card.

So, next time when you are about to elicit requirements, start with the non-functional first.

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!