IT Business Analyst – key role for company success

There are no other ways to build a solid product without foundation/architecture, especially in software development, this matters more than anywhere else. It’s an extremely important stage that determines the subsequent faith in the project more than one might imagine. In the long run, it’s essentially the same as building a house from scratch that will serve you for a long time. You can’t do this without laying the base. And if you do, expect everything to fall apart due to some minor problem that will appear out of nowhere, as the reduction in competitiveness, employees’ demotivation, loss of control over the product, and so on.

In software development, it’s said that the foundation is laid by conducting business analysis. While this may seem obvious to some, the importance of this discipline can’t be stressed enough. If there is anything that can be called the “key to success”, then the business analysis is definitely it.

Yet, despite all that has been said, some call into question this field’s role, trying to diminish its importance in favor of a more abstract and bright word, also known as “vision.”

Even if we talk only about the IT domain, there are several areas related to business analysis: business analytics, system analytics, UX analytics, product analytics, digital intelligence, etc. Today, we focused on business analytics. Let’s talk about it in more detail.

Why does an IT project need a business analyst?

For a long time already, the business analyst has become a key contributor to teams’ success who helps companies to implement and leverage data science, strategy, and analysis. By finding the root causes of problems and organizing business processes, such expert identifies opportunities for enterprises. A business analyst provides suggestions for achieving business goals and increase competitiveness.

Most believe that a business analyst has the same responsibilities as a project manager. This is a myth. The BA is focused on the implementation of nitty-gritty details, while a project manager has targeted product value maximization.

In outsourcing and outstaffing, a specialist of this type is on the front line of communication with stakeholders is involved in gathering projects’ needs, drawing up technical specifications, and much more.
Their main duty is to describe business requirements, which will help to solve several tasks at once. Consequently, BA should turn all requirements into a solution by figuring out why users need a new app or app improvements. Then, determines the user, functionals, and quality requirements which the team can use this data to rate, plan, design, and create a product. It’s huge work.

Most of the companies refuse to develop projects without a preliminary stage of analytics.

Work results

Business Analyst’s daily tasks:

  • stakeholder communications – synchronization with the team (participates in discussions and brainstorms);
  • documentation (drafts specifications in detail, study and analyze realized tasks and value the project’s stage);
  • metric tracking (velocity, budget, etc.)
  • team management (consult with architects, team/tech leads, and subject specialists);
  • self-education and learning (knowledge improvement through mentoring, courses and trainings, applies new knowledge to the project;
  • testing (creates scenarios and test cases).

Project stages

  1. Foundation

In the initial phase, the business analysis aims to establish the basis for a project. In practice, this means:

  • understand of the initial idea of ​​the project and its refinement;
  • fesability assesments, expectations and potential problems;
  • preparation of information for project evaluation.

2. Planning the project

During the planning phase, the business analyst must prioritize the requirements. Another important element in consideration is the assessment of possible solutions. This helps to create a big picture of the project, from which comes an understanding of the real scope, limitations, and risks of the project. The main advantage of each element is the cost-benefit ratio.

All this is stated in the technical documentation. The documentation serves as the basis for the project and determines the way of subsequent management and development. These help to form a basic vision of the user experience for the program, as well as to connect the reality of the situation with the concept of the project.

3. Project supervision

During the execution phase, the business analyst takes on the role of an observer, overseeing the progress of the project in collaboration with the project manager. In practice, this means that the business analyst looks at the background, checking if all the elements in development are going according to plan and on time. It comes to the fore only in cases of new proposals and subsequent adjustments.

At this stage, there are three main goals for a business analyst:

  • breakdown of requirements into task sets for the development team;
  • keeping in touch with customers and getting feedback from them;
  • implementation of feedback and formulation of tasks.

In addition, the business analyst can participate in the development of test cases for the initial stages of testing. Improving the design quality for the proposed IT system to meet user requirements. It’s important to note that the business analyst continues to refine and adjust the functional requirements descriptions throughout the development phase. This is done so that by the time the function is developed, it is described in detail and adapted following the current state of affairs.

4. Project regular review

During the testing phase, the business analyst participates in the development and refinement of complex acceptance criteria for test scenarios of various program modules. This includes a combination of functional walkthroughs, user impersonation, and user acceptance tests. The main goal at this stage is to ensure that the project meets the requirements, its complete readiness, and readiness for deployment.

5. Completion of the project

At the final stage, the business analyst submits the project to the client and receives his approval. His next step is usually to create program instructions and final project documentation.


Business processes systematization

To systematize the entire software process, the business analyst concentrates his energy on a series of actions and procedures aimed at ensuring the continuous operation of the company and its productivity. Thanks to such systematization, the business analyst manages to free staff from routine tasks, increase revenues and competitiveness of the company, and optimize the working time of management.

Before systematization implementation, it’s necessary to:

  • perform a step-by-step analysis of business processes highlighting qualitative and quantitative methods, such as:
    • SWOT analysis of the process;
    • analysis of process problems;
    • analysis of inputs and outputs;
    • resource analysis.
  • define, install and configure the Business Process Management (BPM) system;
  • set up an organizational structure in the system to manage team members responsible for the execution of business processes;
  • determine which business processes exist in the company (using the universal list from the organization APQC (American Productivity & Quality Center), that presents the reference models of business processes) and which of them need to be systematized;
  • describe the selected processes in the system and agree with the management;
  • start and maintain processes.

To manage all work and get an outstanding result, the BA specialist needs a wide range of tools:

  1. Requirements Management: Google docs, inVision Studio, Pencil, Draw.io and analogs.
  2. Project Management: Microsoft Visio, Bizagi, LucidCharts, Axure, Balsamiq.
  3. Requirements tracking and data analysis: Miro, Open Web Analytics, Tableau, Google Analytics, Mixpanel, QlikView BI.
  4. Data Visualization: SEMrush, SE Ranking, KISSmetrics, Ubersuggest, SEOPressor.
  5. Modeling / Diagramming: Cawemo, Diagrams.net, etc.

By excluding analytics from the development process, you are taking on significant risks. Especially if you need to develop a complex product. Yes, it will be possible to save on the reduction of the team, but it will also lead to an increase in the number of reworks, the cost of the project, and the timing of its development.

A business analyst in the software development team is a major advantage. He’s a versatile employee who can plan, calculate and launch a project. He checks what strategies can be used to improve the company’s processes, monitors the economic and technical implementation of new requirements. Experienced business analysts lead the entire system development and strategic development of the company.

DAS Solutions follows all the principles described above. You have the opportunity to recruit a qualified business analyst who has extensive experience working with global projects. It offers customers a product without shortcomings. Contact us today.

34 most common outsourcing questions asked by a potential client

The ICT outsourcing services are seen as a rentable investment to achieve a high level of efficiency in the business. The reason for such a huge interest in nearshore outsourcing is the overload, high demand on in time delivery, expertise, and experience that outsourcing companies may complement their clients.

62% of large organizations are outsourcing at least a portion of their application development work. (Computer Economics study, IT Outsourcing Statistics 2014/2015)

Considering that DAS Solutions is using and is integrating the latest technologies, we thought it would make sense to address the questions we hear the most from customers. The purpose of these answers is to simplify the perfect IT outsourcing service provider selection process and give you insights on how to gain trust. Likewise, for companies that are in the selection of the right development outsourcing partner, to know the right answer could be helpful in the selection process, avoiding some of the most expensive pitfalls.

59% of companies outsourced work to reduce costs. (Microsourcing)

A business owner could save around 60% of overall costs with outsourcing. (Outsource Accelerator)

Outsourcing can increase productivity by 10 to 100 times. (Economist)

Continue reading this article, discovering surprising and unexpected juicy details about which you probably did not even know.


Recruitment and Project Management

1. How do you recruit specialists to work on the project? / Where do you find your candidates?

When we have talents available in house, we offer their CVs to the customer with whom we have concluded the agreement. After a detailed examination of all provided CVs, the client invites the chosen candidates to interview, having the right to refuse or to select the best candidate/s.
Once the client needs a specific specialist while is not available in our team, we resort to multi-stage recruitment. It gives us a hand to meticulously review applicants’ backgrounds. The stages of recruiting that we rely on:

CV screening – we analyze the candidate’s expertise;
Technical interview – we exam talent’s English-language competence, his vision, values, experience and we offer tasks which should be completed, verifying the candidate’s technical skills;
Discussion with the CEO.

2. What do you look for when hiring new developers/candidates?

Our primary focus during candidates’ selection is skills and ability to solve problems, here we refer to the solution-oriented value. Likewise, for us, it’s important how they act in different situations, for which we follow multiple approaches. We are delighted to say that a big part of our experts is qualified, certified, and highly experienced.

3. How skilled and researched is your development team?

Many of our specialists are constantly developing their skills and knowledge. Moreover, all personnel undergoes training, certification at a certain time.

4. What is the size of the team that will be involved with my project?

Following the audit and the advanced analysis, we come up with recommendations on the number of talents for each position needful to successfully develop the product. It depends on the project-specific requirements, expected delivery time, and the team configuration that would assure the best result possible.

5. Could one employee handle multiple functions?

Some of the candidates who are involved in providing ITO are trained to handle multiple tasks efficiently. This might be the case for the full-stack programmers, who are able to work on the back-end and the front-end of the project or applied to the golden team of DAS where our Seniors may perform as System Architects/Team leads and regular developers.

6. How do you deal with the rotation of people in projects?

To ensure maximum effective work of developers, we have a backup professional/s who is/are up to date with the project and other useful information, otherwise, we do agree with clients on the recruitment process to ensure that all positions are covered.

7. Will I have to train your employees?

Our experts constantly develop their skills and knowledge, being well trained and coached. The client can train employees at the initial stage, if there are more specific nuances such as particular processes, workflows, management systems, etc.. This training is requisite to align us and avoid misunderstandings in the future. See more details and recommendations in our blog article.

8. Will I have to supervise your employees?

For faster product delivery, an efficient and effective step, avoiding misunderstandings and mistakes, we suggest you get actively involved in the product development process. Online meetings through a dedicated communication channel 2-3 times a week are king advice from our side. In our experience, this method is the most beneficial to save customer’s and provider’s time, effort, and resources, providing a quality product.

9. How will I get to know that your team is working or not?

To ensure the implementation of tasks at the most effective level, we organize daily meetings and monitor the evaluation of tasks. Likewise, the time that is worked by each person is monitored by a special tool predestined for such processes. We also offer a weekly / monthly report of the tasks performed and the worked time by each developer.

10. Will the developers assign to my project work on any other project at the same time?

Every expert who is involved in product development is dedicated at the highest level only to this project and in none other than it.

11. Will the same people be assigned to my project for the length of the development effort?

In order to deliver an excellent client experience in time, we strive to proffer a long-term contract according to the client’s needs in the development and maintenance phase. We understand how important this aspect is.

12. How easy will it be to scale a team by 1/3/5 developers? How much time do you need?

It takes about up to 2-4 weeks to scale a team by 1/3/5 developers, depends on the needed number. If the client felt the need for this, we recommend to communicate as soon as possible.

13. How long does it take to start a project? / Where do I start?

Once we made a deal with the client, usual the kick off takes two to four.

14. How will you manage the project?

In order to manage the project, namely to estimate the implementation time of the activities, it is indispensable to have as much information about the company as possible.

15. What collaboration tools do you use during projects?

All communication with the client takes place through a dedicated communication channel and corporate email, protecting business data by Transport Layer Security (TLS) and Secure Real-time Transport Protocol (SRTP).

16. What is the client’s role in the project, and how much time is needed from the client?

The experiences we’ve had, show that the more the client gets involved in the project and our collaboration, the more successful the result is. Why does it work like that? As a result of the permanent communication, we simply understand the client’s needs. On the other hand, the client is always informed about what is happening with his project and at which stage it is, providing feedback when he deems it necessary. So, we get the final result in the desired time.

17. How do we communicate during a project to surface the progress, plans, and problems?

A regular schedule of online meetings, 2-3 / week, will provide a clear vision of the current situation of the project and problems. During these meetings, both sides will come up with solutions, ideas, and with the next steps of the activities.

18. Do you use decent technology?

We use the latest in regards to technologies, databases, tools, etc.


Documentation and Partnership

19. What are the first steps of cooperation?

Depending on the client’s need, we analyze in detail the requirements, materials, and documentation. Consequently, we offer qualified experts (developers/project managers/quality assurance engineers/business analysts, etc.). Additionally, we prepare the action plan and confirm it with the client.

20. How do you deal with partners in different time zones?

Analyzing our experience with overseas clients, we realize that we have never had problems with the time zones’ difference, while at the same time our experience is not that big with this, our 90% of our clients are from Europe.

21. How do you structure the partnership roles to be efficient and successful?

In order to avoid delays in project delivery, it is essential to discuss from the start the development processes and the attributions of each part that will appear.
Working with the client contains:

  • ultimate transparency;
  • maximum involvement;
  • sincerity and straightforwardness;
  • dedication and availability.

22. How do you ensure software quality?

To guarantee the code’s quality, we rescue to the frontend, backend, and infrastructure code audit. We pay special attention to this stage, accomplishing it in several ways:

  1. Automated code study through scanners that check the code for various parameters for each pull request. Plus, we’re checking issues typical of a particular programming language, for instance, Java often has problems with garbage collection and memory leaks. These language-specific issues should also be monitored during the code audit process.
  2. One more step in code review is based on the examination of code quality, architecture, optimization, the functionality of the code following compliance with the customer’s requirements.
  3. Our QA Engineers conduct stress and security tests, unit and integration tests. These validate complex scenarios and usually require external resources, like databases or web servers, to be present.

23. What will be the cost of my product?

There is no straightforward answer to this question because the final price is affected by many factors, including both your specific requirements and external market factors:

  • project type and app complexity;
  • team;
  • design and UX;
  • technologies;
  • testing;
  • target group size;
  • maintenance and others.

Get in touch with us for an appropriate estimate.

24. How do you support security compliance?

From the outset of the product development, developers are informed related to the client’s policy and regulations. In such a way, only the professionals involved in the project have access to the code, adhering to all standard security and encryption procedures in the process. Therefore, we protect customer data, ensure security compliance, and deliver proper security documentation that includes:

  1. features and components with firewall configuration;
  2. vulnerability patching;
  3. incident response;
  4. intrusion detection systems;
  5. demilitarized zones;
  6. intrusion prevention systems and more.

Once the experts work remotely, we use VPN, so only some people have access to production servers, where they can make changes.

25. How much access should I give to your team?

Usually, in order to get into the essence of the project and to fully understand the client’s needs, values, is necessary to offer:

  • technical requirements (as comprehensive as possible);
  • business process documentation (step-by-step description);
  • mockups.

26. Do you subcontract your services?

Yes, sometimes, though prefer to keep all the work in-house. We cooperate with reputable companies in a similar field. Our understanding has been friendly for many years. When recruiting, we turn to our partners, sometimes subcontracting their talents.

27. Do you provide a service-level agreement (SLA)?

Of course. To ensure a 100% beneficial collaboration for both parties, both customer and provider, we certainly use the service-level agreement (SLA) which includes the list of assistance actions, end-to-end program management, and deliverables.

28. How flexible is the SLA?

Depending on the project’s needs, the number of needed professionals and other resources will change. In this way, the SLA is as flexible as possible.

29. Who will own the source code?

The client is the sole code owner with all the intellectual property rights.

30. Do you provide technical documentation?

Definitely. We offer technical documentation which contains the road map, code, and methodology of the project.

31. What is your reporting process?

The reporting process, which we provide, contains the standard set of reports, a work timeline where is mentioned the date of delivery of each report, we use a well know reporting system.


Experience and Practice

32. For how long are you in the outsourcing business?

We have 8 years of experience in delivering the IT Outsourcing service. During this period, we have successfully helped companies across Europe to find the right IT experts for their projects.

33. What kinds of companies do you typically do work with?

Since 2013, DAS Solutions has gained the recognition and trust of more than 40 customers globally from the following industries:

  • Insurance;
  • Finance & Banking;
  • Ecommerce;
  • Telecommunications;
  • Healthcare and Pharmaceuticals;
  • Transportation;
  • Travel and Booking;
  • Business Management;
  • Retail;
  • Real Estate;
  • Agriculture.

Our team has put a lot of effort into creating, implementing, successfully carrying customers’ projects of different levels.

34. Why are you better than other software houses? What makes you special?

During 8 years of work, in any situation, we remained customer-oriented, offering quality and justified costs. DAS Solutions is a company that has won the trust of customers through receptivity, open mind, dedication, and appropriate actions in stressful situations. We can certainly say that we are among the TOP in the region IT Outsourcing providers.

Wrapping up

We have listed some of the most frequently asked questions in the context of IT outsourcing, whose goal is to help companies reduce their costs and increase their productivity by working with the right customer to win the customer’s heart. Of course, the topic is broad and there are still many questions that others are looking for answers to. We’d be glad to arrange a call to begin answering any additional questions. Contact us, we may be the outsourced IT partner you were looking for.

Tell us about your project


    By using this form you agree with the storage and handling of your data by this website.
    Send me NDA

    The danger of legacy

    Today, software development takes place in a highly competitive environment. This introduces several significant risks that may affect business performance and one of the most dangerous is excessive efforts to maintain legacy technologies. Although businesses may be hesitant to make investments in new technology, the true cost of legacy technology far outweighs the investment. Because legacy applications cost more to run and maintain, they make the business highly inefficient, increases operational costs and system downtime. Legacy technologies are also extremely vulnerable, because many of these outdated systems are no longer supported by the manufacturer. Another problem with using outdated technology is that most legacy systems are incompatible with newer systems.

    Risks

    However, scrapping legacy systems and replacing them with more modern software involves significant business risks. Most managers try to minimize risks and therefore do not want to face the uncertainties of new software systems. Replacing a legacy system is a risky business strategy for a number of reasons. There is rarely a complete specification of the legacy system. The original specification may have been lost or not written in sufficient detail. Therefore, there is no straightforward way of specifying a new system that is functionally identical to the system that is in use.

    New software development is itself risky so that there may be unexpected problems with a new system. It may not be delivered on time and for the price expected.

    Keeping legacy systems in use avoids the risks of replacement but making changes to existing software usually becomes more expensive as systems get older. There are several reasons that lead to an increase in the complexity of system maintenance. First of all, different parts of the system may be implemented by different teams. There is, therefore, no consistent programming style across the whole system. Replacement of developers is a completely normal business process, but it is necessary to strictly adhere to the code style and follow the architecture guidelines.

    Optimization

    To eliminate the risk of obsolescence of a programming language or framework, it is desirable to divide the application into separate services with a minimum number of dependencies. If necessary, any of these services can be rewritten using new technologies and this will in no way affect the functionality of other parts. In addition to dividing into separate services, the use of modular architecture and the CQRS principle allows you to divide functionality within a service.

    During the development process, it is necessary to allocate time for creating and updating the documentation so that it does not become outdated. All documentation should be structured and it is advisable to use specialized tools for writing and storing documentation. All business processes should be described in the form of UML diagrams.

    The system may have been optimized for space utilization or execution speed rather than written for understandability. This causes particular difficulties for programmers who have learned modern software engineering techniques and who have not been exposed to the programming tricks that have been used. In the long run, clear and easily modifiable code is always preferable to an optimized but overcomplicated solution.

    Adherence to uniform standards, division into independent services, timely updating of documentation allows you to gradually develop the product without the need to rewrite it completely.

    Drop us a line if you have legacy code/systems, we have the right experience to help you to make the right decision on it’s future.

    Tell us about your project


      By using this form you agree with the storage and handling of your data by this website.
      Send me NDA

      One Sprint in DAS Solutions life

      It’s not a secret that having an Agile mindset is absolutely essential for Business Development.

      Nowadays, everything is changing very fast, we have a lot of challenges, and therefore, it’s all about how fast you can react and how fast you can adapt to changes.

      Changes are inevitable!

      It’s something that we have to welcome, because in this way, we will become less stressed and more powerful, we will see a situation from different angles. The problem is that during years, we were comfortable to work according to plan, without any deviations, because for a lot of people, to change something means that they need to perform some additional work, recalculate costs, they will have some additional communication channels, some additional risks and as a result, another deadline. It’s true. To work according to the plan – is a really great way to reach your objectives and strategic goals. However, it’s not so easy and you always will deal with changes, due to different factors, such as: Business need, Market change, etc.

      First of all, in order to manage a change, we really need to “Accept” the idea that changes are something you can’t control until it happens. This is the critical element that we have always to keep in mind. It’s a long process to capture this idea, however, it is something fundamental.


      From our perspective, we don’t think that sticking just to one approach or methodology is the best way to reach your goals. We really believe that Team need s to be flexible and adaptable to different situations. We prefer to mix methodologies for a better outcome. We want to give our team all knowledge and instruments that will make their work more comfortable and productive.


      So, as an IT company, mostly, we are using SCRUM, but in addition, we add some instruments and techniques from other frameworks, such as Waterfall, to get a better outcome. We are opened to experiments, and always are in the process of continuous improvements of our processes.

      Usually, our Sprint begins on Monday (it’s more comfortable for us) and the duration of the Sprint is 2 weeks or 10 business days. Before we are getting to start our Sprint, we need to perform some activities to make sure that everything that was planned – will be delivered.

      These events include:
      • Backlog Refinement or Grooming,
      • Sprint Planning,
      • Daily Scrum,
      • Retro meeting and Review.

      So, first of all, imagine that you have a list of hundreds of requirements. We all understand that these can’t be delivered in 2 weeks, therefore, we need to prioritize our Backlog to make sure that first of all, we will deliver the most important features from a business point of view. This type of meeting usually is performed with the Product Owner, who is responsible for Ordering Product Backlog items and, ensuring that the Product Backlog is transparent, visible and understood. It’s a very important part of our process, because the team, which consist of 7 people, must have a clear understanding of what needs to be done, its acceptance criteria, estimations and to know the amount of User Stories which will be included in the Sprint according to team capacity. Also, we are assessing additional risks that might or might not happen and track them daily. Risk Analysis is based on the Probability and Impact of an event/risk that might happen in the future, having a positive or negative result.

      A Grooming or Refinement meeting is a meeting where we prioritize all items in the Backlog from those which bring maximum value. To make it happens, we use different techniques for prioritization:

      1. MoSCoW Prioritization scheme — The MoSCoW prioritization scheme derives its name from the first letters of the phrases “Must have,” “Should have,” “Could have,” and “Won’t have”. This prioritization method is generally more effective than simple schemes. The labels are in decreasing order of priority with “Must have” User Stories being those without which the product will have no value and “Won’t have” User Stories being those that, although they would be nice to have, are not necessary to be included.
      2. Paired Comparison — In this technique, a list of all the User Stories in the Prioritized Product Backlog is prepared. Next, each User Story is taken individually and compared with the other User Stories in the list, one at a time. Each time two User Stories are compared, a decision is made regarding which of the two is more important. Through this process, a prioritized list of User Stories can be generated.
      3. 100-Point Method — It involves giving the customer 100 points they can use to vote for the User Stories that are most important. The objective is to give more weight to the User Stories that are of higher priority when compared to the other available User Stories. Each group member allocates points to the various User Stories, giving more points to those they feel are more important. On completion of the voting process, prioritization is determined by calculating the total points allocated to each User Story.
        Our favorite prioritization method is MoSCoW, due to its simplicity and efficiency. Regardless of what method you use during the prioritization phase, all of them offer a simple idea – “To choose items which are most important and valuable for the customer.

      After our Backlog is prioritized, and team understands what is important for the customer for the next Sprint, we have a Sprint Planning meeting. Usually, we are doing this meeting on Friday, because the new Sprint, with prioritized Backlog, estimated effort of User Stories and tasks begins on Monday. Therefore, during the Sprint Planning Meeting we discuss and estimate each User Story in terms of the effort required to complete it.

      Here we can use different techniques to estimate the effort for each User Story:

      1. Planning Poker
      2. Fist of Five
      3. T-Shirts Size
      4. Bucket System
      5. Points for Cost Estimation

      But mostly, we are using:

      1. Planning Poker
      2. Fist of Five
      3. T-Shirts Size

      Planning Poker, also called Estimation Poker, is an estimation technique which uses consensus to estimate relative sizes of User Stories or the effort required to create them.
      In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in a sequence and the numbers represent the complexity of the problem, in terms of time or effort, as estimated by the team member. The Product Owner chooses a User Story from the Prioritized Product Backlog and presents it to the team. The Scrum Team members assess the User Story and try to understand it better before providing their estimate for developing it.

      Then, each member picks a card from the deck that represents their estimate for the User Story. If the majority of all team members select the same card then the estimate indicated by that card will be the estimate for that User Story. If there is no consensus, then the team members discuss reasons for selecting different cards or estimates. After this discussion, they pick cards again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached.

      Planning Poker advocates greater interaction and enhanced communication among the participants. It facilitates independent thinking by participants, thus avoiding the phenomenon of groupthink.
      Planning Poker is a really great technique for effort estimation, but how would you do it for people who work remotely?


      We have found an extension for Project Management software that we use for all our projects. It gives us a possibility to estimate the effort remotely, using the same cards with the Fibonacci sequence, but online.

      Mostly, we prefer this technique to Estimate all User Stories, because we believe that communication and agreement between team members – is the key to success.

      Fist of Five
      Is a simple and fast mechanism to achieve consensus in a group and drive discussion. After an initial discussion on a given proposal or a pending decision, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers. The value in using this technique is not only consensus building but also driving discussion because each team member is asked to explain the reason for their ranking. They are also given the opportunity to express any issues or concerns. Once the team has discussed it, a collective decision will be made.
      The number of fingers used to vote indicates the level of agreement and desire for discussion:

      • One finger: I disagree with the group’s conclusion and have major concerns.
      • Two fingers: I disagree with the group’s conclusion and would like to discuss some minor issues.
      • Three fingers: I am not sure and would like to go with the group’s consensus conclusion.
      • Four fingers: I agree with the group’s conclusion and would like to discuss some minor issues.
      • Five fingers: I wholeheartedly agree with the group’s conclusion.

      T-Shirt Size
      Is a technique used for relative estimation and high-level sizing of Items/User Stories. You use this technique of relative estimation as opposed to absolute estimation when you just need a rough estimate or comparison of items. Speed is valued over accuracy which stops people from overthinking and overanalyzing, as you just want people to use their instincts and gut feeling. Information may not be available at this point anyway for detailed estimates.
      You can have as many t-shirt sizes as you like, but best to keep it simple as it’s only a rough estimate.
      The most common amount is 4 – Small, Medium, Large and Extra-Large.

      The main difference between the 2 commonly used techniques (Planning Poker and T-Shirt size) is based on what amount of User Stories will be estimated. In Planning Poker, you can estimate less Use Stories than in T-Shit size, because Planning Poker is about the interaction between people, communication amongst them and reaching consensus. According to Scrum rules, for the Sprint Planning meeting we have no more than 4 hours for 2 weeks of the Sprint. That’s why if you will use Planning Poker, you can’t estimate a lot of User Story (usually you can estimate less than 15 User Story per session). Instead, this type of effort assessment, gives us a clear understanding between team members, many details could be discussed, and a lot of risks could be identified, just because people communicating with each other.


      There is a lot of information about using Scrum Planning meeting and many suggestions on how to use it correctly, but we really believe that we need to use only what works for us better, what brings value for our company, what makes a customer satisfied and a team is happy and productive.

      Just to be cleared at this point, there are several recommendations that the Sprint Planning meeting should be divided into 2 parts :

      1. User Story Estimation and the
      2. Tasks Estimations to complete this User story.

      Our Sprint Planning Meeting includes just User Story Estimation. It means that the effort required to complete each User Story is estimated during this meeting. With regards to tasks, all team members are responsible for decomposing the User Story into small manageable pieces/tasks, as well as estimate these decomposed tasks. This can be done during a Sprint Planning meeting or not. Formally, we don’t have a specific rule for that. Only one point is important: to have as much as possible of Estimated User Stories and Estimated tasks before the start of the next Sprint.
      
      We use several techniques to estimate tasks, based on how accurate an estimation should be given for each task and what information do we have about these tasks. Of course, it is important to give a real estimation, which is very close to reality, that’s why we are using some techniques to make it happen:

      • Analogous estimation means that will be used estimation based on experience from past projects. It’s not so accurate estimation technique, but you can use it for high-level estimation.
      • Parametric Estimation is a more accurate technique for estimating the cost and duration of the task. It uses the relationship between variables to calculate the cost and duration. Parametric Estimation is determined by identifying the unit cost or duration and the number of units required for the project or activity. The measurement must be scalable in order to be accurate. In other words, you need statistical data.
      • 3Points Estimate is a part of the Program Evaluation and Review Technique (PERT). This method based on 3 points to calculated weighted mean or so-called Beta Distribution.

      Formula:

      Most Likely Time is the most probable, therefore, it has the biggest weight.

      Pessimistic Time – the worst scenario. When everything goes wrong, there are a lot of risks, constraints
      Optimistic Time – good scenario. When everything goes according to the plan
      Most Likely Time – most probable. When everything goes according to the plan, but we assume some risks or changes can happen in the future.

      Further, you need to calculate a Standard Deviation, to understand possible deviation from the initial plan.

      Standard Deviation Formula:

      When we know everything what we have to do in the next Sprint, we create the Sprint Backlog.
      The sprint backlog is a Backlog of prioritized Items /User Stories, their estimation, acceptance criteria and Definition of Done.


      Every day we have a Daily Scrum meeting which focuses on understanding what issue or blocking points we have and what we will do with that. This is in addition to standard questions like “What did you do yesterday?” and “what are you planning to do today”. Each team makes their Daily Scrum different, depending on what you want to capture during this meeting, but we believe that: “If it works for you and brings value- do it this way!”. This is exactly what Agile mean s for us. And of course, the duration of this meeting is less than 15 minutes.
      A Sprint is finished with a presentation of the deliverables that were performed in a span of 2 weeks. Of course, we have a situation, when a deliverable is too big and it takes more time to show how it works, however, the goal of each Sprint is to make sure that we have usable increment at the end of the Sprint.


      One of the main points of any project is Lessons Learned, no matter what timeframes you are working on. We really believe that learning makes us better, therefore, after each Sprint, we look at what we can do better, what we are not going to do in the next Sprint and what went well. One of the important points of Retro meeting is to make sure that all suggestions for what needs to be improved are tracked and will be implemented. We are not discussing improvements just for being discussed! We are tracking all team’s feedbacks and the team decided what, when and how it can be improved, so that, each next Sprint gets better.

      In a nutshell

      It’s really safe to say that all Scrum ceremonies and techniques help you manage your projects properly, but if you don’t have a flexible mindset, if you don’t want to change, adapt and respond to challenges- you may never achieve your goals. The first thing we need to do – is just to understand that there is always a way to make you perform better, just open your mind and experiment.

      Tell us about your project


        By using this form you agree with the storage and handling of your data by this website.
        Send me NDA