Business Analyst: Are you designing for a disaster...

What intentional and unintentional errors in business analysis can lead to...and what impact it can have. This blog provides a guide to help the business analyst understand the consequences of errors in requirements and designs.

Unintentional:

One of the most unlikely incidents occurred due to a software bug in the Therac - 25 medical radiation therapy device in 1985-87. This machine was used to administer radiation doses on patients, and in several cases the faulty device administered excess quantities of radiation. In some cases, it exceeded 100 times more than the intended dose, and resulted in several injuries and three deaths.

(Source: https://en.wikipedia.org/wiki/Therac-25)

Technology is like a 'Gift of Fire,' as correctly mentioned by Sara Baas in her book where she gave many examples of such disasters.


Correlating to her thought, it would be appropriate to ask a business analyst, “are you designing for a disaster?”


Many business analysts working on a project, especially a large project, fail to see the complete picture. This alone can lead their company or their client to the disaster.

Along with software design, development and testing, requirement analysis and design is key part of developing software solutions.


It is the business analyst who elicits a particular requirement or functionality document, confirms, and sign it off before communicating the requirements to the technical team. The requirement states precisely how it works under normal conditions, in an alternate process and possible error it may have.

What are the rules applied to the requirement? What is acceptable and not acceptable in terms of data, rules, format and so on?If the error lies in the requirement/functionality, intentionally and unintentionally goes undetected, could it lead to major disaster depending on the project/product it is used?For example, a decimal place mentioned incorrectly in a requirement document in banking software that deals with millions of transactions could potentially make a serious impact with loss of few millions dollars.

A particular requirement or function used in laser arm robotic surgery could be seriously impaired.

Defective transportation software could potentially cause loss worth millions and delay.

A space ship or flight software could cause an accident if any fault occurs in the system.

These are just a few examples of the thousands of potentially damaging situations that could arise if the software requirements are not documented and implemented correctly.


Intentional:


Of course, there could be intentional error in the requirements for designing the software solution to mislead authority. The most notorious example is how Volkswagen managed to manipulate the car emission system for two decades. Of course, when they are caught, they have to cough up close to 18 billion dollars in penalties, not considering the loss of face and brand value.

Oops...How brilliantly one can misuse the use of software... The team of business analyst/stakeholders/project manager who designed software never thought it would ultimately cost billions...

(Source: http://time.com/4046994/volkswagen-emissions-golf-crisis/)


Undetected hole in the ozone layer over Antarctica: This is another serious issue that impacts the whole world. The software that was used by NASA to map ozone layers had been designed to ignore certain values that deviated greatly from expected measurements.

Therefore, the hole in the ozone layer went undetected until 1985, even though the project was launched in 1978. It was only found after the scientists at NASA reviewed the data for abnormal results and found the error and the big hole.

(Source: http://royal.pingdom.com/2009/03/19/10-historical-software-bugs-with-extreme-consequences/)

The business Analyst's role goes far beyond the requirement lifecycle, as their role and responsibilities are not limited to just requirements or the solutions...but the total solution and its overall impact on the organization and beyond. Their contribution could possible make or break the organization.

Please read my book for more details: Business Analysis: The Question and Answer Book available on Amazon and other places in Kindle and paperback.

#BusinessAnalysis #Design #Disaster #SoftwareDevelopment #RequirementManagement #ProjectManagement

Disadvantage of being business analyst

As we have seen, there are many benefits to being a professional business analyst. However, no one ever talks about dark side. Here are few points that you need to watch out for if you wish to build a successful career in business analysis.

Getting it done without Authority: Being positioned in a central role, the business analyst has to be a Jack of all trades and juggle numerous duties and responsibilities. These duties can range from managing stakeholders (from the CEO to the end user who is generating a report in some corner) and maintaining an IT department along with balancing a unique set of requirements specific to the task.

It sounds difficult, but that’s the fun. Not everyone is a people person.

Value Creator: Sometimes you need to elicit requirements, confirmation and enter into communication with stakeholders when they each have their own BAU and other priorities. Beware that at times, stakeholders do not always see value in business analysis efforts and respond accordingly.

Know it all: While joining a new role, the hiring person/line manager mentioned that they knew I was new to the domain and they were fine with it. However, after 3 months, the same person suggested I obtain more knowledge than the SMEs and senior director who had been working there for over 10 years.

It is an unrealistic expectation to require business analysts to have a deeper and wider knowledge of the domain than the stakeholder. To elicit the requirements in the correct way, boil down the question to its simplest and purist form, and manage the scope at the right place.

If the BA changes the domain, then it is like starting all over again.

Super Dynamic: The business analysis is very dynamic profession as they are the first to react to new changes in business/industry such as new regulations, laws, codes of practice, business processes and methods.

The business analyst often has to walk on a challenging path through both the academic and practitioners' world, acquiring new knowledge and skills and implementing them effectively in real life situations.

If you are not quick to adapt to new circumstances and conditions, it will invariably lead to frustration.

Superman(woman)’s Confidence: A good BA must have the confidence to stand up for their points to present, negotiate, and manage conflict (if it arises) using logic and every weapon in their arsenal. Remember, the audience could be anyone in the organization.

Unsung Hero: Think of the person who provides ideas to integrate business with technology to create a million (or billion) dollar enterprise. For example, the iPod that changed the music industry or airbnb who revolutionized the hotel industry. The identity of these individuals remains largely unknown, unless he/she happens to be ‘Steve Jobs!’

Most modern inventions that applied technology and innovation to industry are a direct result of business analysis that created billions of dollars of revenue, but many are yet to get their dues.

However, the situation is changing. Being a professional BA is now considered a proper career and many organizations, both profit and non-profit, are working towards making it even better.

Apart from these pitfalls, being a BA is fun!

What Business Analyst needs to know about Agile Approach?

Here is the brief blog written on "What Business Analyst need to know about Agile approach?" in Q & A form. It is helpful for you to know about Agile in-depth and will also be helpful in preparing you for your Business Analysis interview. This blog will focus more on Scrum as it is more popular and widely used Agile approach. My next blog will have summary of other Agile approaches.

Please explain - what is Agile.
Agile is an approach to project management that is used in developing software solution. It is group of methodologies based on incremental and iterative approach to help the team to respond to the unpredictability of building a software solution. It also helps the team to explore the solution as requirements continuously evolve through assessment and adaption while producing the software solution through a series of demonstrable, executable releases of product/project.

The process can be custom-made by development or client or organization optionally based on the technical constraint, organizational standards, team’s comfort, or project scope, budget.

The point to remember that every iteration progressively contributes to developing and delivering the solution.

Following are some of the ‘Agile’ methodologies:

· Extreme Programming
· Scrum
· Lean Software Development (LSD)
· Feature Driven Development (FDD)
· Dynamic Systems Development Method (DSDM)
· Agile Unified Process (AUP)
· Adaptive Software Development (ASD)
· Kanban

Scrum is most commonly used Agile approach in the modern IT environment.

What are agile manifesto?

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Explain Scrum. How did you use it in your last project?

We used Scrum as it is the most preferred agile framework. We applied in managing and controlling iterative and incremental software solution (projects).

(for additional information: Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed considerably to the evolution of Scrum.

The “Scrum’ is derived from rugby game where the ‘scrum’ means of restarting play after a minor infringement.)

We applied common strategies of Agile as follows:

• Sprint consisted of 3-4 weeks that was delivered in the form of workable component or feature.
• Informal communication: It was close interaction among small team (2-12). 
• Light and informal communication: Along with informal communication and informal process were followed. These meeting were frequent and face-to-face to understand the progress from every team members and resolved the issues, if any.
• Change management: was informal and changes were welcome at late stages
• Customer collaboration: Each iteration or sprint was delivered to user to access. The changes or improvement were done during the following release(s).
• Informal Process: Every sprint or iteration was part of product or solution. End of the release the component, the remaining components were assessed and prioritized for the next development. If any new component was added and was found to be important, it was accommodated before other complements were developed depending on the prioritization. This prioritization was part of every post release activity and no changes were added once the Sprint was in the process.
• From technical perspective, every iteration or Sprint was considered as a mini-project that went through entire lifecycle phases (define, requirement analysis, design, development, test and deployment) in compressed and fast paced mode.

What is Product Backlog?

‘Product Backlog’ is a prioritized Backlog containing the end user requirements. It is also a prioritized list of features (requirements or bug fixes, non-functional requirements, etc.) that contains short descriptions of all functionalities desired to be implemented to deliver the working or potentially shippable increments of the software product or solution.

This is used in place of traditional requirement specifications such as BRD (business requirement document) or a product roadmap or SRS (Software Requirement Specification).
The product owner owns the product backlog. Product owner along with cross-functional team estimate and sign off to deliver potentially shippable increments.
Stakeholders and other team members can add stories / features / functionality / requirements to the product backlog in the form of ‘To-Do’ list.
Product backlog is enough to start work in Scrum instead of lengthy formal documentation used in traditional project management approach.

#	User Story	Priority	Estimation
1	As an authorized user, I want to access ‘manage beneficiary’	1	2
2	As an authorized user, I want add a beneficiary	2	3
3	As an authorized user, I want to edit beneficiary	3	1
4	As an authorized user, I want to set transfer limit to the beneficiary	5	1
5	As an authorized user, I want to receive alter on my registered mobile phone after completing the transfer	6	2
	Total		9

• Each story adds a value to the user/customer.
• Each story is prioritized and developed in an order.
• Any team members can add a story and delete (his/her) story at any time during the project life cycle. 
• However, a “Sprint” (or iteration) can’t be changed by adding or removing story. 
• The product backlog is analyzed and re-prioritized after every “Sprint” and based on the prioritization, the stories are selected for development for the next “Sprint”
• The Product backlog is updated during entire project life cycle.
• All stories are estimated.
• All the stories are complete within and no low level tasks are added in the product backlog.

What do you understand the term ‘an epic’ in an agile project?

There are many requirements scattered across the multiple areas of the complex solution or product. The segregation and grouping of the User Stories belonging to the same domain is known as ‘an Epic’. An Epic is complete when all the User Stories are added and concluded.

What is the User Story in Agile?

A User Story is a requirement / feature / functionality described in the form of a story. User Story explains ‘who’, ‘what’ and ‘why’ of a particular requirement.

For example: As an authorized user, I want to access ‘manage beneficiary’ to add the new beneficiary.

This will define:

Who - authorized user,

What - access ‘the manage beneficiary’ functionality,

Why - to add the beneficiary

During the life cycle, these user stories are identified, prioritized, and selected for a Sprint for implementing. They are further specified into tasks, estimations and other details related to tasks.

What is Sprint?

Sprint is an iteration or basic unit of scrum approach. It is typically consist of 3-4 weeks or 30 days. Software solution / software product is delivered through successive sprints.

What is a sprint backlog?

Similar to Product backlog, a sprint backlog is a list of features and requirements that team shall achieve in the next sprint. It is based on requirements priority and development team’s ability to complete the work.

What is the sprint-planning meeting?

The sprint meeting is conducted at the beginning of every sprint. The product owner, scrum master, and development team member(s) meet to understand the capability of the team, create the ‘sprint backlog’ by prioritizing the items, plan and delegate the work for the sprint. Although some mention 8 hours required for the sprint-planning meeting, but, there can’t be a fixed duration of the same as the components may not take same duration to discuss and finalize.

What is Daily Scrum Meeting?

As name indicates, these are short terms strategies. Every day during the sprint, the team assembles to discuss the progress of the sprint and strategy, if necessary. It is short (average 15 min long) and informal that can be even done at the team member’s desk.

Each member in turn answers three questions:

1. What did I do since the last Scrum meeting?

2. What do I plan on doing between now and the next Scrum meeting?

3. Do I have any roadblocks?

What is Scrum (Kanban) Board? What is a ‘Story Board’?

This board represents the progress in the ‘Agile’ approach.

You can create virtual or manual story board by placing note on each section.

The column indicates the stage and row indicates the User Story/task in a particular stage.

This is an excellent way to represent the status of the User Stories/tasks along with the project.

Design	Development	QA Testing	UAT	Deployment	Done
Task L	Task H	Task E	Task C	Task B	Task A
Task M	Task I	Task F	Task D
Task N	Task J	Task G
Task O	Task K
Task O

Or

Product Backlog	In Sprint (Development)	Delivered
Task F	Task C	Task A
Task G	Task D	Task B
Task H	Task E
Task I

Explain Sprint Review Meeting.

At the end of sprint or on the last day of the ‘Sprint’, there are two ‘sprint review meetings’ – one for customer review and demonstrations and other for team to review for the possible improvements. The adequate time is allowed (some can calculate by deriving the value from.

The duration of the meetings may vary. For each week of sprint duration, apply one hour of meeting time for the customer review. For the retrospective, apply .75 hours (45 minutes) for each week of Sprint duration. For example, a 30-day Sprint would result in a four-hour review and three hour retrospective. A two weeks Sprint would result in a two hour review and a one-and-a-half hour retrospective. Additionally, the team should spend no more than one hour preparing for the review.

These are the meetings that review - what was achieved in the course of the sprint and what is left.

What is Sprint Retrospective (meeting)?

Team members analyze the past sprints to understand the "lesson learned"  from the previous project to avoid similar mistakes and improve continuously.

What is Scrum Framework?

It outlines broad guidelines for scrum projects with few rules (dos and don't), roles (Product owner, Scrum master, scrum team), artifacts (deliverables or prioritized backlog) and events (Scrum Planning Meeting, Scrum Meeting, Sprint Review Meeting etc.) to deliver a software solution or products via iterative, interactive, and incremental approach.

This framework provides guideline for the role, nature of customer collaboration, communication.

It works on a principle of:

- Continuous improvements - inspect & adapt policy to engineering processes, product, and requirements.

- Change Management – is an integral part of project life cycle.

Thus, the framework allows defining only high-level requirements at beginning and low-level requirements at later stage/during implementation.

Communication: Scrum Product Owner collaborates with scrum master and scrum team to identify and prioritize the user stories/functionalities.

Why do we use a sprint burn-down chart?

It is graphical presentation of the progress of the sprint that is updated daily during the sprint.

Explain the Scrum Team and their role?

Scrum Team comprises of Product Owner, Scrum Master and the Development Team.

Product Owner:

Product Owner is a primary stakeholder of the software product/solution. He works intently with the team to create product backlog by identifying, adding, modifying and prioritizing the user stories.

Scrum Master:

Scrum Master works as a facilitator to the project team. He manages resources, enforces the scrum rules on the team, lead the scrum meeting, and guide the team as required.

Scrum Team:

The team decides what and how much they can do in a given project iteration or a Sprint. The team is responsible for developing and delivering the sprint.


What the term ‘Spike’ in scrum?

Spikes are time bound planned activities or sessions between the Sprints created for analyzing or answering queries.

What is the Velocity of a sprint?

It is the capability of the team to complete the work during a particular Sprint that is derived from analyzing the historical data.

What is ‘Tracer Bullet’?

The ‘Tracer Bullet’ is a ‘Spike’ or analyzing session using latest technology, latest architecture and latest best practices in the industry to produce top quality product.

What do you know about ‘Impediment’?

Impediments are ‘the causes’, which are hindering the team or team member to achieve their goals or maximum capability.

What do you mean by ‘ScrumBag’?

‘ScrumBag’ is the person or group or any factor responsible for ‘Impediment’.

Do you know ‘Invest’ in Scrum?
‘Invest’ suggests the characteristics of a good ‘User Story’ based on following criteria:

Autonomous: No other ‘User Story’ is depending on.

Zero-Trade-Off – No further negotiation required for this

Value – User Story brings in sizable value to the end product.

Scalability – The User Story can fit various sizes easily

Testability – It is testable to verify the success criteria of implementation of the User Story.

What is Planning Poker?
It is bringing consensus among the team on estimation of a particular User Story during planning phase.

Planning Poker Cards are distributed to the team members. Each card has a number that is associated with estimations in the form of either hours or days. Once a User Story is selected, every team member is asked to display their card that conveys their estimation for that User Story. If all the cards display the same number, that number (estimation) is finalized as ‘estimation’ for the User Story.

In case the cards displayed have different numbers for a User Story, estimations are discussed and finalized by brining everyone on an agreeable term.

Reference: 

1. Agile Estimation and Planning by Mike Cohn

2. Scrum Institute 

(http://www.scrum-institute.org)