What is the role of an analyst? What do they do? Is the analyst needed in the project? These questions come up quite often in various organisations, articles or at conferences for analysts. The answers vary depending on the role of the person answering, the habits of the organisation, the way projects are managed or their size.
When looking for a job as an analyst, you will find out that the range of duties that can be performed on this position in each company, and even within the same company but during different projects can differ quite a bit. First of all, when talking about the position of the analyst we can distinguish: business analyst, system analyst and IT analyst.
an analyst working on software and computer systems development. In practice, this position combines competences of a business analyst and a systems analyst
However, these terms, too, are often used interchangeably, or used with different meanings.
There are times when smaller projects lack a designated analyst, which is why some believe that such a person is not necessary. However, that is not completely true because the other members partially play the role of the analyst in such a case. Regardless of whether we have the analyst in the project or not, it is necessary to develop requirements, define business processes and prepare the required documentation. Nevertheless, without the analyst, there will be a lack of additional insight into whether the needs of the business are well understood by the developers, if certain functionality has been overlooked and consequently whether the product in development is what the business wants.
The role of the analyst in agile working methods and methodologies
The stereotypical role of the analyst in IT comes strictly from the cascade methodology or so-called waterfall. Unfortunately, even today this method of project management is still equated with the analysis stage and the extensive documentation that needs to be prepared. Arrangements with the client, which should be unchangeable, as well as long implementation time of new solutions caused that the project was becoming unprofitable and inflexible. Newer approaches to running projects, the “more agile” ones, are trying to solve these types of problems. Hence, the role of documentation has been minimized, the focus has been set on working and delivering the solution so that the customer could see the results of the work from the first stage and participate in its creation. But does this mean that every project can be carried out this way? The metaphor often used for this question is “building a bridge”. I don’t think anyone can imagine building a bridge without having access to a full, detailed documentation that from the very start provides for the use of suitable materials. Either way, standard methods are becoming obsolete in the IT world. So what about the analyst?
In the theoretical aspects of the Agile methodology, the analyst is not dead, only their role is perceived differently. In the standard approach the analyst was often confused with the scribe who was supposed to create 500 pages of documentation, while in case of agile frameworks their responsibility has been clearly defined.
DSDM (Dynamic Systems Development Method) shows the role of the analyst as the bridge between the business part and the technical part (the only part of the “snowman” – DSDM diagram – that has two colours) and the connection between the project level and the solution development team (between the head and the body). It can be said that this role becomes the backbone of a project that has to reconcile many various points of view (which can be translated into many different needs of various teams and user groups).
DSDM places the analyst near the development team while AgileBA promotes the analyst outside the teams but does not limit the variability of the function. Thus, in practice, several analyst roles can be distinguished, as described below.
Analyst as a Product Owner Assistant
In practice, the analyst supports creating user stories as well as managing the product backlog, collects data and helps to arrange the implementation plan. Good information flow is the foundation of collaboration with the Product Owner since the situation where each of them has their own version of truth cannot happen.
Analyst as a member of the Scrum team
In this case the analyst executes the project in sprints, which enforces time constraints on their work and may impair its effects. Faster doesn’t necessarily mean better. The granularity level of the analysis must appropriate so that the amount of work fits into the given sprint. This approach encourages the analyst to go beyond their primary role and take on other tasks like testing or sometimes even coding. Working closely and constant contact with developers is undoubtedly beneficial.
Analyst outside the Scrum team
The analyst works independently from the software development process, thanks to which they have more research capabilities and can revise their analysis more closely. The analyst is not burdened to such extent with the deadlines arising as a result of sprints taking place every couple of weeks. Unfortunately, the biggest drawback of this approach is the lack of close cooperation with developers and good understanding of their needs.
Analyst as a Product Owner
The analyst in their primary role is responsible for the value of the solution delivered to the stakeholders, has subject matter knowledge, knows the needs, requirements and problems concerning the solution that is being created. That’s why in practice they are the one who most frequently takes over the role of the Product Owner, if necessary. Obtaining decision making power, defined as the arrangement of tasks in the backlog, their priorities and order of execution, gives the possibility to deliver value in the built solution as soon as possible. Additionally, a good analyst with high facilitation skills naturally takes on the role of the Product Owner and thus takes into account the interests of many user groups, builds relationships with them, pursues conversations and negotiates.
Analyst in SDN research and development projects
As you can see above, on any given project, the analyst’s role is a variable and there is no single, strictly held position. Each project needs to establish this internally and appoint people to carry out the project-wide analysis. In order to ensure the widest possible range of competencies in SDN projects, analysts together with architects have created a group that is at the same time an independent team (comparable to “Analyst outside the Scrum team”) and is a support for the Product Owner (comparable to “Analyst as a Product Owner Assistant”), whereas the area in which they work (marked in green) is presented in the figure below, layered on the development process.
Analyst’s work area in an SDN project
In SDN projects, analysts together with architects are responsible for preparing data, based on which the developers can implement the given functionality. The first analyst’s task with respect to a given functionality is to develop requirements enabling the architect to create a high-level description of the solution. In the light of the high-level description, analyst develops user stories and complementary test cases, which are useful for the architect’s low-level description of the solution, created together with the development team.
Analyst participation in the development of materials for developers
Analyst work products and their relationships
This is the first task performed during the implementation of the functionality. In order to properly carry on the task, it is necessary to know the business needs that we want to achieve. Requirements are developed for this purpose. This includes functional and non-functional requirements.
These points are often a supplement, detailing the business requirements that are developed by the Product Owner. Developing requirements, apart from collecting business needs, often requires getting acquainted with the given functionality. Presented business needs do not always include the whole required scope that is expected and will be necessary for implementation. The developed requirements must be prioritized. The MoSCoW prioritization method (Must have, Should have, Could have and Won’t have) is used for this purpose .
M – the requirement must be met,
S– the requirement should be met if possible, but the success of the project does not depend on it,
C– the requirement can be met by the project,
W– the requirement will not be included in the project.
The developed requirements often concern the whole functionality that is completed in several iterations (within several epics), therefore the requirements are correlated with given release or epic. Additionally, the requirements are verified in accordance with the MVP (Minimum Viable Product) defined for the project.
Architects verify the requirements and create high-level solutions in line with them.
Creating user stories
The architects’ vision of the solution concerns its full functionality. Unfortunately, based solely on that it is often difficult to make time estimations of the works related to the implementation of the given functionality or to define relevant developers’ tasks. User stories are created to facilitate the understanding of a given problem (requirement), to indicate the possibility of breaking it down into smaller steps and to sequence their execution.
|The scope of each user story is usually presented in the form of the following template:
As an <actor> I want <action>, so that <achievement> where:
The user story should have the following qualities, according to its definition:
- Sized correctly,
Stories developed in SDN projects usually have majority of these qualities, but not all of them. The deviations are based on the desire to make the developed material as useful as possible while preserving the other criteria. The written stories are very often dependent on other ones in order to keep their size appropriate so that they can be completed within one sprint (2 weeks).
Acceptance criteria are defined for each user story i.e. a list of requirements and conditions to be met, that determine whether the story has been correctly executed from a business point of view. In addition to the acceptance criteria, the following points should also be addressed:
- link to requirements – a reference to requirements that are implemented as a part of a given user story, which makes it possible to verify whether all specified requirements for a given functionality have been covered within user stories;
- prerequisites – conditions that must be met in order for the story to be implemented;
- relationships between stories – indicating which stories are conditional, dependent or related to a particular story helps to determine the order in which tasks related to given stories should be performed;
- additional information – pointing to materials that will facilitate, further explain the implementation of the story;
- identifying test cases – identification of possible test cases that verify the execution of the user story.
User stories are reviewed by architects and the development team working on the given functionality. These stories need to be accepted by the developers who, based on them, make the valuation of time needed for a given functionality implementation.
Development of tests cases
One of the criteria that stories must meet is their testability. Analysts write down test cases in order to complete the description of stories, to determine exactly what conditions and requirements must be satisfied as well as what exceptions should be included. Test cases are created according to the scenario given – when – then.
Scenario given – when – then:
GIVEN – represents the data that will serve as the input data, on which the method under test will operate
WHEN – represents the tested
The test cases are designed to:
- provide developers implementing a given functionality with overview of how it should behave in different scenarios, further detail the description of stories;
- present to developers testing the solution what they should pay attention to, what to consider when testing the functionality;
- indicate to the Product Owner which conditions must be fulfilled by the given functionality.
The role of the analyst and working in this position is not simple at all. Often, you need to develop your own system of work tailored to the needs of a particular project. This is also how it is implemented in SDN projects. Division of labour is not a rigid criterion and we often step into the role of other responsibilities. In addition to the framework that has been developed we need to engage into lot of work related to familiarising ourselves with new standards on the market, the possibilities of their application, as well as researching ready-made solutions. With the whole team, we research, search, verify and design a solution to make a telecommunications revolution and create the “network of the future”.
 A Guide to the Business Analysis Body of Knowledge®, Version 2.0, International Institute of Business Analysis, Toronto 2009, http://www.theiiba.org.
 A Guide to the Business Analysis Body of Knowledge®, Version 3 Public Review, International Institute of Business Analysis, Toronto 2014, http://www.theiiba.org
 The National Occupational Classification 2011 (NOC 2011), Human Resources and Skills Development Canada and Statistics Canada, s. 214.
 Jerzy Leyk: Role analityka biznesowego – standard ITIL versus BABOK.
 ISCO-08 Draft definitions, ISCO International Standard Classification of Occupations, July 2009, http://www.ilo.org/public/english/bureau/stat/isco/docs/gdstruct08.doc
 Agile Buisiness Consortium, Chapter 7: Roles and Responsibilities https://www.agilebusiness.org/page/ProjectFramework_07_RolesResponsibilities