Thursday, August 25, 2016

Common Business Analyst Deliverables

Common Business Analyst Deliverables

 Project Stage
 Document Name
 Brief Description
 Project initiation
 Vision document
Business case
Feasibility study
 The purpose is to:
·       Set out and gain consensus of the direction of the project and scope from the senior stakeholders.
·       Justifies the benefits and estimated costs.
·       It will provide enough evidence that the money is worth being spent, allow funding to be agreed or will show that it isn’t worth doing which then prevents further money being wasted.
·       It makes sure that the overall solution is agreed and that it will meet the business needs.
Business process mapping document
 It contains “as is” and “to be” business process diagrams.  The purpose of it is to:
·       Understand the business processes.
·       Help identify the problems and opportunities for change.
·       Understand the scope of the requirements as each requirement should relate to a process.  This is why it should always be done before the business requirements document.
·       Business stakeholders are more likely to be know their business processes better than their requirements.   Therefore this is a better starting point and further justification for doing this first.
 Business requirements document
 It contains a catalogue for all of the business requirements, a priority for each and a justification.
The purpose of it is to:
·       Gain a consensus and understanding of all of the business requirements in scope for the project
·       Understand which of the requirements are mandatory to the extent that if they weren’t delivered the project would not be worth doing.
·       Pre-requisite for being able to start system requirements to ensure trace-ability.
 Use case model
Context diagram
 It contains a use case model which is a UML (Unified modelling language) tool or a context diagram.
The purpose of it is to:
·       Identify system boundaries (which systems are in scope).
·       Identify the use cases (goals) for each of the systems in scope.  This is a summary of all of the things the system has to do.
·       Identify the human and system interfaces for each of the goals.
·       Allow estimation and planning depending upon the number of use cases and the complexity and size.
·       Pre-requisite for the system requirements.
 System requirements document
Functional requirements document
Use cases
User stories
User story boards
 It contains all of the requirements that need to be met by the project systems in scope.
The purpose of it is to:
·       Ensure the system requirements will meet each of the relevant business requirements and is understood and acceptable to the business stakeholders.
·       Ensure the system requirements are understood and acceptable to the IT stakeholders.
·       Allows developers to code the systems in scope according to the system requirements.
Non-functional requirements document
 It is really important that non-functional requirements are gathered early on and aren’t missed out.
The purpose of it is to:
·       Set out non-functional requirements.  A non-functional requirement is a quality, constraint or behaviour that the system being built must meet.
·       To ensure the system being developed is adequate as involves a wider variety of IT stakeholders than the developers and a wider set of questions to the business stakeholders.  For example will the system have adequate enough capacity for the volumes of data anticipated.
 Data mapping document
 This document focuses on data requirements.
The purpose of it is to:
·       Identify all of the types of data required and agree a consensus of the names to be used and definitions.
·       Identify all of the relationships between each type of data and the data down to field/attribute level.
·       Provide a logical data model which can be used to work out a physical data model.
·       Ensure all of the data required can be met.
 RFP stands for Request for proposal. It is written when goods or services are required from an outside supplier where no products or expertise are currently available to meet the needs of the project within the company.
The purpose of it is to:
·       specify the needs and allows other companies to bid for the work.
 Evaluation scoring matrix
 This is written in conjunction with the RFP.  The purpose of it is to:
·       Agree the success criteria to ensure the best vendor is selected.
·       Allow all scorers to follow the same success criteria.
·       Provide objectivity to the process
 Options paper
 If problems are encountered the business analyst can write an options paper.  The paper should be short and:
·       Specify the problems encountered and the reasons.
·       What the potential options are to resolve the problem.
·       Make a recommendation with reasons
The purpose of it is to:
·       Allow problems and resolutions to be understood and agreed so the project can proceed.
 Design / testing / implementation
 Gap analysis document
 This may be carried out at several stages to ensure that what is being produced traces back to:
·       The requirements.
·       The scope.
·       The benefits expected.
 Testing / implementation
 Test strategy / test scripts
 Normally tester deliverables, however there may be occasions where the business analyst may contribute to writing the, be a reviewer, carry out testing or help co-ordinate with other testers and business users.
The purpose of it is to:
·       Ensure all of the different business scenarios will be met by the system being changed.
 Testing / implementation
 Training materials / new business processes
 Normally a trainer deliverable.  However there may be occasions where the business analyst may document new business processes and ensure training manuals are kept up to date.
 Testing / implementation
 Handover documentation
 If the business analyst encounters several problems during the delivery process they may be best placed to put a handover document together for various parties to ensure resolutions have been formally captured.  This is particularly important if any new manual workarounds get introduced as a result.

Tuesday, May 3, 2016

Ideas to improve documentation in AGILE

AGILE isn’t about documentation” I am sure many of us must have heard it. Believe me, it’s not the truth. There are many documents required to be created as a part of project management in AGILE. Product owners and scrum masters are the ones who primarily work on the documentation related tasks. But it is a collective responsibility of the team and you shouldn’t be surprised to see many documents being worked upon by the scrum team. When the main target (in AGILE) is to deliver the product in the shortest possible time, it becomes essential to know some ideas and tips that help practitioners spend less time on documentation without impacting its quality. Here are some cool tips –
  • Keep it short and simple (KISS): While in AGILE documentation, the idea is not to decrease the number of documents (or reduce the importance of documentation), the idea is to have crisp and short documents which will speak only about the key items that are essential for the document and not linger around providing unnecessary details.
  • Frequency of document updates: Number of updates happening in AGILE are much more than that in traditional processes. This is because updates keep happening almost in every iteration; however that in traditional mainly happens only in the beginning of the cycle. If you don’t see updates happening on the documents (or anyone document) then try to understand the reason behind it?
  • Pair review: Quality has to be maintained not just at the product level but also at the documentation level. It is hence important to review and improve documents. Pair review is a concept followed for the same purpose. These are informal reviews usually done within the team by other team member and suggestions are implemented in the document.
  • Automate exhaustively: Try to develop tools, (on excel / other office tools) that can automate the tasks for documents and save time. This saved time can be used in other project management / product development activities.
  • Non-functional requirements: Agile teams have a practice of treating the non-functional requirements as story points. Creating separate stories make those tasks appear as separate entities. However it is not the right practice to adopt. Making performance and other non-functional requirements core to the functionalities is the right strategy and that’s what managers should practice to save time in the cycle.
  • Avoid overlap: AGILE is about focusing most on the product that is being developed. Hence minimizing the number of documents, their contents and yet covering all essential aspects in the documents should be targeted. It hence becomes necessary to plan documentation in advance, have clear and crisp templates and avoiding overlap across multiple documents.
  • Simplify content display: A lot of times teams end up creating multiple documents because it becomes difficult for them to find the right content at the right time. Having easier ways to display documents and their contents is the key. Using technology and thus document management systems comes handy in such scenarios.
Thus these tips will help practitioners save a lot of time on the documentation and process related items and focus more on the final output i.e., product delivery and frequent updates (thus improvements). Business will see more features and functionalities in the product and will find more returns to their investments. End users would be happy to see better quality product with good performance and usability (points that are usually neglected due to lack of time in product development). Thus, these tips may not seem to show direct impact but will indirectly help business get more returns on their investments and help in improving the quality of the software.

Waterfall vs Agile Documentation

It is said that Agile document is ‘just barely good enough’ and is produced ‘just in time’ and with ‘just the optimally right amount of content’. Less documentation and time spent in it saves project cost however this shouldn’t come at the cost of increased project risk of not documenting essentials. In this article we will notice how Agile and lean philosophies have shaped the documentation practices too and how those are different from the ones as observed in Traditional approach.

What are the documents created in waterfall (and other traditional) methods?
  • Project charter: Gives information about the scope, objectives and participants in a project.
  • Vision statement: It’s a 1-2 page document that focuses on the plan or main vision behind a particular project.
  • BRD: It’s an acronym for business requirement document. It focuses on questions like ‘what’ to deliver? ‘How’ to delivery? & ‘When’ to deliver?
  • Functional requirements: It consists of a list of all functional requirements for the software being developed.
  • Non-functional requirements: All the nonfunctional requirements like performance, usability, security, etc. are enlisted in this document.
  • Project plan: Contains the entire project schedule and plan. The document enlists the different resources that are working on a project and
  • Architecture & design: Describes at high-level the outline of the software and includes its major components. It also includes the list of drivers that can impact the architecture.
  • Wireframes: It’s a blueprint that gives skeletal framework of a website.
  • Test plan: Contains the test strategy, methodology, approach and list of test cases as will be covered while undergoing the testing cycle.
  • Deployment and maintenance plan: Talks about the deployment schedule, the team members who would be assisting the developers in deployment cycle. The approach that the team members will follow and risks.
How AGILE documentation is different?
Light documentation: In Agile stakeholders try to keep the documents light and low in terms of content. Teams don’t beat around the bush and try to cover all essential points in smaller content. The document is nimble and stakeholders keep in mind the rule of ‘too little documentation and you are in trouble, too much of documentation and you are overloaded’.
Evolving document: As the team progresses into sprints, the requirements and thus the documents keep updating and evolving. Every stakeholder is responsible for appropriate documentation for that project and in daily scrums; any changes to documents get discussed. Also since the frequency of updates is very high, a document management system is used to manage the various versions of the documents.
Document communicates: Communication is an essential key when it comes to managing projects involving cross boundary teams. In such scenarios documents play a key role and are used to track communication. In a lot of AGILE projects, the same concept is followed and laid a huge emphasis on.
Documentation throughout the cycle: In traditional methodologies a lot of time in the initial part of the cycle is invested into documentation and large documents are created. In AGILE documentation and changes on the same keep happening throughout the cycle. Thus agile projects can focus on implementation and delivery right from the beginning of the cycle.
User manuals: Agile doesn’t produce documents like requirements documents or design documents. However it does produce documents like user manual, operations manual, etc. The focus is not on producing ‘to-be-built’ document but on creating ‘as-built’ document.
Document ownership: In Agile the ownership of document lies with not just the project / test manager but it lies with every team member. In sprints as and when different tasks are identified for the team members, document related tasks can be assigned to them.
Thus Agile brings in a lot of differences when it comes to the documentation strategies. These strategies are further built upon the agile principles and inculcate a feeling of collective responsibility (on documentation), continuous improvement and focus on end product. Creating user manuals instead of requirement documents shows Agile team’s focus on serving the end product and its customer even while building documents that are essential to manage the projects. Collective ownership can inculcate a feeling of responsibility amongst the team members and can help each get more clarity on the project and the timelines. Agile thus brings a lot of improvements in the documentation methodologies and saves a lot of time when compared with the traditional approaches.

Software Development World - Agile vs Waterfall Methodologies

There are several ways to develop software, two of the most prominent methods being waterfall and Agile. And as anytime there are two ways to go about something, a debate rages about which is best. Does it matter really? Doesn’t either way give you a product?

What is the waterfall methodology?

Much like construction and manufacturing workflows, waterfall methodology is a sequential design process. This means that as each of the eight stages (conception, initiation, analysis, design, construction, testing, implementation, and maintenance) are completed, the developers move on to the next step.
As this process is sequential, once a step has been completed, developers can’t go back to a previous step – not without scratching the whole project and starting from the beginning. There’s no room for change or error, so a project outcome and an extensive plan must be set in the beginning and then followed carefully.

Advantages of the Waterfall Methodology

1. The waterfall methodology stresses meticulous record keeping. Having such records allows for the ability to improve upon the existing program in the future.
2. With the waterfall methodology, the client knows what to expect. They’ll have an idea of the size, cost, and timeline for the project. They’ll have a definite idea of what their program will do in the end.
3. In the case of employee turnover, waterfall’s strong documentation allows for minimal project impact.

Disadvantages of the Waterfall Methodology

1. Once a step has been completed, developers can’t go back to a previous stage and make changes.
2. Waterfall methodology relies heavily on initial requirements. However, if these requirements are faulty in any manner, the project is doomed.
3. If a requirement error is found, or a change needs to be made, the project has to start from the beginning with all new code.
4. The whole product is only tested at the end. If bugs are written early, but discovered late, their existence may have affected how other code was written.
Additionally, the temptation to delay thorough testing is often very high, as these delays allow short-term wins of staying on-schedule.
5. The plan doesn’t take into account a client’s evolving needs. If the client realizes that they need more than they initially thought, and demand change, the project will come in late and impact budget.

When should you use waterfall methodology?

1. When there is a clear picture of what the final product should be.
2. When clients won’t have the ability to change the scope of the project once it has begun.
3. When definition, not speed, is key to success.

What is Agile?

Agile came about as a “solution” to the disadvantages of the waterfall methodology. Instead of a sequential design process, the Agile methodology follows an incremental approach.
Developers start off with a simplistic project design, and then begin to work on small modules. The work on these modules is done in weekly or monthly sprints, and at the end of each sprint, project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run.
The process, with its lack of initial design and steps, is often criticized for its collaborative nature that focuses on principles rather than process.

Advantages of the Agile Methodology

1. The Agile methodology allows for changes to be made after the initial planning. Re-writes to the the program, as the client decides to make changes, are expected.
2. Because the Agile methodology allows you to make changes, it’s easier to add features that will keep you up to date with the latest developments in your industry.
3. At the end of each sprint, project priorities are evaluated. This allows clients to add their feedback so that they ultimately get the product they desire.
4. The testing at the end of each sprint ensures that the bugs are caught and taken care of in the development cycle. They won’t be found at the end.
5. Because the products are tested so thoroughly with Agile, the product could be launched at the end of any cycle. As a result, it’s more likely to reach its launch date.

Disadvantages of Agile Methodology

1. With a less successful project manager, the project can become a series of code sprints. If this happens, the project is likely to come in late and over budget.
2. As the initial project doesn’t have a definitive plan, the final product can be grossly different than what was initially intended.

When should you use Agile methodology?

1. When rapid production is more important than the quality of the product.
2. When clients will be able to change the scope of the project.
3. When there isn’t a clear picture of what the final product should look like.
4. When you have skilled developers who are adaptable and able to think independently.
5. When the product is intended for an industry with rapidly changing standards.
Both the Agile and waterfall methodologies have their strengths and weaknesses. The key to deciding which is right for you comes down to the context of the project. Is it going to be changing rapidly? If so, choose Agile. Do you know exactly what you need? Good. Then maybe waterfall is the better option. Or better yet? Consider taking aspects of both methodologies and combining them in order to make the best possible software development process for your project.

Agile Methodologies

Agile has 6 methodology and they are XP, Scrum, ASD, Crystal, DSDM and FDD


AGILE advocates to minimize documentation task and invest more time on core development activity, however the degree of documentation differ in different approaches. –
  • XP (Xtreme Programming), Scrum, ASD (Agile software development) & Crystal don’t put a lot of emphasis on documentation and minimum documents are created
  • Teams following FDD spend sufficient amount of time in documentation.
  • DSDM requires some documents to be created & degree of documentation is less than that of FDD and more than that of XP

End user involvement

Another significant difference of AGILE with that of traditional methods is that Agile advocates involvement of end user in the software development process. However the involvement of end-users in different formats is different. Eg., –
  • End-user is actively involved in XP
  • Product owners represent end-users in Scrum
  • In ASD, DSDM and Crystal end-users participate in all of the incremental releases
  • In FDD, end-users participate through reports

Team meetings

Extensive communication is also a core principle of Agile and the level of communication differs in the different approaches.
  • Informal daily stand up meetings happen in Scrum & XP
  • Information sharing is through documents in FDD and DSDM
  • Face-to-face meetings happen in Crystal and ASD

Size of projects

The size of projects and the teams also differ as you move from one method to another.
  • While Scrum, DSDM, FDD and Crystal can be followed for projects of any size, methods like ASD and XP are only followed for smaller projects

Sprint Cycle

The iteration time period also differ in the different methods. Here is how they differ –
  • DSDM advocates producing 80% of the solution in 20% of the time
  • XP has a sprint cycle varying from 1 week to 6 weeks
  • Scrum -> 2 to 4 weeks;
  • ASD -> 4-5 weeks
  • FDD can have a smaller sprint cycle too (2 days) and it can vary upto 2 weeks (based on project requirements)

XP (Xtreme Programming)

  1. End users (customers) are actively involved in the process of software development. Hence the product developed is very close to what the customer wants.
  2. Team feedback is also taken very seriously and there is a lot of focus on self-improvement
  3. Best practices are well-defined and religiously followed within the teams
  1. Documentation is given less emphasis and hence giving reference to an issue / instance in past (while working on projects) is a challenge
  2. At times it is difficult to bring in customer into the team since he is very distant from the development team. Hence some other team member (like sponsor / PM) plays the role of the customer. Thus lack of discipline observed at times

DSDM (Dynamic systems development method)

  1. Allows for efficient project management and strong control on the project lifecycle
  2. Requirement priority approach helpful in delivering most important functionalities first
  1. Documentation is complex and time consuming


  1. High level of communication is observed in Scrum teams and which increases focus on problem resolution, product improvement and team improvement through feedbacks
  2. It offers certification. Hence it becomes easy for organization to know who are experts and hire people who are ‘certified’
  3. Harvard Business Review has spoken a lot about Scrum. Hence it must be something which can be taken seriously in the business

  1. Poorly documented and hence it is too easy to be abused
  2. Product owners have lose control on the project
  3. Changing requirements allow customers to get tempted to keep demanding more and more functionalities

FDD (Feature Driven Development)

  1. Multi-tasking is possible in case of FDD
  2. Methodology can be used in case of applications that are complex because of documentation and reports that are created
  1. Complexity is so much that there is no point in using this method for smaller projects
  2. Less communication within and out of team. Thus teams learn less from other individuals and teams


  1. High risk and highly important component are delivered first
  2. Effective team communication and this facilitates learning amongst team members from each other
  3. This methodology can be adjusted as per project type and team size
  1. The planning & development are not depended on requirements, hence traceability is an issue in Crystal