Recent Posts

Pages: [1] 2 3 ... 10
Business Analyst Concepts Discussion / Re: What is RACI matrix
« Last post by 172624703 on July 17, 2017, 12:15:27 pm »
RACI is an acronym for Responsible, Accountable, Consulted, and Informed. The RACI Matrix enables you to identify who is responsible, accountable, consulted, or informed, for every task which needs to be done in a project.

Here is some more detail about what each letter in the RACI acronym means:

Responsible   This is the person or role responsible for performing the task, that is, the actual person doing the work to complete the task.
Accountable    This is the person who is ultimately accountable for the task being done in a satisfactory manner. Essentially, the Accountable person must sign-off the work that the Responsible person produces. Typically the owner of the process will be the Accountable person. There should only ever be one Accountable person per task.
Consulted   Those people whose input is used to complete the task, thus, communication with this group will be 2-way in nature.
Informed   Those people who are informed as to the status of the task, thus, communication with this group is 1-way in nature.
Business Analyst Concepts Discussion / Re: Basics of Gap Analysis
« Last post by 172624703 on July 17, 2017, 11:49:51 am »

Gap Analysis is a strategic planning tool to help you understand where you are, where you want to be and how you’re going to get there.
Here’s a simple Gap analysis chart:
Here's an example of a GAP analysis for profit
Here’s the Gap Analysis process:
Step 1: Decide the topic you’re going to do the Gap Analysis on? This is the challenge you’re trying to tackle.
Gap Analysis sample topics include:
•   Revenue
•   Profit
•   Market Share
•   Product Functionality/Features
Step 2: Identify where you are right now based on metrics or attributes.
•   Revenue — We’re at $10 million in annual sales right now
•   Profit — We’re at $1.5 million in annual profit right now
•   Market Share — We have 7% of the market share right now
•   Product Functionality/Features — Our product has was just launched so it has limited features
Step 3: Identify where you’d like to be over a specific time frame?
•   Revenue — We’d like revenue to grow to $25 million in annual sales by 2021
•   Profit — We’d like profits to grow to $8 million per year by 2021
•   Market Share — We’d like to own 15% of a particular market by 2021
•   Product Functionality/Features — We’d like our product to have industry leading features by 2021
Step 4: Identify the gap between where you are and where you want to be.
•   Revenue — They gap is $15 million per year in annual sales by 2021
•   Profit — The gap is $6.5 million in annual profit by 2021
•   Market share — The gap is 8% market share by 2021
•   Product Functionality/Features (let’s use Web site as an example) — The gap is that you’d like to have the following features by 2021: a blog, a sign-up form to let visitors follow your business on Facebook and Twitter and a way for customers to buy products directly.
Step 5: Determine how the Gap should be filled.
•   “6 M’s”
o   Manpower — The people resources you need.
o   Methods — The processes you need.
o   Metrics — The measurements you need.
o   Machines — The automation or technology you need.
o   Materials — The material items (such as physical goods or marketing collateral) you need.
o   Minutes— The time you need.

Business Analyst Concepts Discussion / Sprint backlog
« Last post by 172624703 on July 17, 2017, 11:38:20 am »
Need sample Sprint backlog in JIRA
Here’s how to actually write them.


The I.N.V.E.S.T. guideline to writing user stories is almost universally accepted as the standard to work by. The acronym was made popular by Bill Wake’s original article from 2003.

(I)ndepdendent: You should be able to prioritize and rearrange user stories in any way with no overlap or confusion.

(N)egotiable: As previously discussed, a good user story can be reworked or modified to best suit the business. User stories are not an explicit set of tasks.

(V)aluable: User stories need to be valuable. By this, we mean valuable for the business or the customer. If it’s not, why would you have your team work on it?   

(E)stimable: A good user story can be estimated. It’s also important to differentiate time estimations from an exact timeframe. A rough estimate is beneficial to allow teams to rank and schedule their priorities. At Sprintly, we allow users to categorize their stories and sub-items into sizes (small/medium/large/extra large) so that they can better prioritize their stories.

(S)mall: We definitely recommend keeping your user stories small. While we don’t suggest an exact timeframe to stay in, writing user stories that focus on smaller tasks allows for greater focus. The larger a story is, the harder it is to estimate and easier it is to get caught up in sub items that should have probably been their own stories.

(T)estable: Before a user story is written, it is essential that a criteria to test it is in place. Outlining the testability first ensures that the story actually accomplishes the goal you are trying to achieve. A story is not finished until it is tested. For maximum productivity and team alignment, make sure your team knows how their work will be tested.

We tend to view testability as the fourth major component of a user story. Having your team know your stories’ testing parameters beforehand plays a big role in how they decide to take it on.


With I.N.V.E.S.T. in mind, you can now start thinking about writing user stories. At Sprintly we consider any project that contains sub-components a good candidate for a user story. Sub-items are tasks or tests you can list under your user story to provide a clearer vision of what needs to be done before the user story is complete.

Once again, it’s important to remember that everything about a user story, including its sub-items, can be reworked to best fit the needs of your business. Sub-items are great for providing additional direction and details for what needs to be done. Take this user story for example:

As a User
I want an easy way to export my data into CSV
So that I can analyze usage data outside of the tool
Basically, non-functional requirements relate to qualities of the system that cut across user facing features, such as security, reliability, and performance. Non-functional is probably a bad name because it sounds like these requirements are intangible, simply properties of a static system. However, these requirements do affect the function of the system and it is possible to design tests that these qualities are present.

The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one-shot like a user facing feature. Alternative terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements" but let’s stick to calling them "non-functional requirement" (NFR) for now. So they have to be considered in every development cycle and factored into our test strategy.

NFR can be grouped into:

Execution qualities, such as security and usability, which are observable at run time.
Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.
 Non-functional requirements describe how the system works, while functional requirements describe what the system should do.
This does not mean the latter are more important, but most requirement gathering techniques focus on functional requirements, so large gaps in non-functional requirements are common.
So what exactly are we looking for here? Well, here are four examples of Non-Functional requirement groups; usability, reliability, performance, and supportability.
Business Analyst Concepts Discussion / Re: what are the thumb rules of BA
« Last post by 170123204 on July 09, 2017, 02:06:14 pm »
This article is intended to be the starting point for a discussion on rules of thumb (or heuristics) for business analysis activities. It describes some principles I think are important to practice in all situations which have served me well
Every analyst will have developed their own rules of thumb over time. If you ask them to list them they will probably struggle because they tend to be instinctive and require some reflection and thought.
I have spent some time thinking about my rules of thumb and hope you find these useful. This is probably incomplete and when others list their rules, in some cases.
Writing user stories is dead simple if you follow these simple steps:

1. As a [role], I can [feature] so that [reason]

When writing user stories, using this pattern is a for sure bullseye. Let’s look at an example:

As a account owner, I can check my balance online so that I can keep a daily balance 24 hours a day.

Pretty easy right? However, in some instances I find that the “so that” suffix reads redundantly so go ahead and have that be optional if you wish.

As a account owner, I can check my balance online.
Turning your idea into a reality is a bit more complicated than just handing your design over to a manufacturer or developer and waiting for the profits to roll in.
Market Research Before you spend a lot of time and money creating a product, you should know if anyone will want to buy it. Look at what's out there and size up the competition. Do products that are similar to your idea
Develop a prototype. Once you've found your market and ensured that your legal path is clear, it's time to start bringing your idea to fruition. Monosoff said a good prototype can be as basic as a drawing or diagram, or as complex as a working, professional product.
Take time to research. Inventing a product requires a lot of initial investigation, patience and resilience, Lininger said. Before you begin the process, make sure you have the time to dedicate to due-diligence research. This is especially true when you're looking at patent protection for your idea.
Continually test your product. Helgeson reminded entrepreneurs that their products are not going to be perfect in their first iterations. You'll have to tweak the product and make some changes along the way, and the best way to figure out those changes is by testing your invention with real consumers. Get honest feedback from test groups as a way to validate your idea
Business Analyst Concepts Discussion / What is RACI matrix
« Last post by 172732205 on July 09, 2017, 10:46:44 am »
What is RACI matrix
Pages: [1] 2 3 ... 10