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

    Tech Skills Will Make You a Better CEO

    A set of technical skills will bring each CEO closer to the IT department. Tech skills allow leaders to understand more about methodologies in which software is developed. Even basic knowledge of how software operates gives managers ideas about how it can be improved or modified. New tech skills help managers communicate and present their vision more effectively. Managers who continuously learn new things and foster innovation are perceived as better leaders by their employees.

    Kevin Systrom explains on Quora that he has become the CEO of Instagram because he spent his nights learning to program. At some point, he was able to build a prototype of his idea in HTML5. He showed it to investors and raised $500k. Instagram appeared thanks to Systrom’s determination and new skills he acquired.

    Get acquainted with programming languages

    Basic programming courses will help dig into the world of programming. Personal experience with coding greases the wheels with everything from time management to delegation. Signing up for IT newsletters helps keep track of major trends. A CEO has to understand what  the IT department is talking about at least on a conceptual level. He or she generally must have an opinion about it, so acquaintance with the terminology will let them feel in their element.

    Master technical writing

    Technical writing allows one to engage in a project. In the process of describing technical tasks and features, one remembers the information about the process and timing during which an IT project is created. Technical writing brings the CEO closer to speaking the same language as software engineers.

    Learn about Agile

    Agile project management methodology turns work in a collaborative, flexible process. It allows to find out more about employees and ways in which they react to exceptional situations. Additionally, projects are delivered based on evolving business requirements which increases competitiveness.

    Be proficient in SQL

    A leader who knows how to create queries using SQL can work with different types of databases and generate reports that are important for the decision-making process. Data analysis plays a major role in the identification of customer preferences, trends, and issues at early stages. A survey conducted by PwC says that 63% of CEOs are using digital technologies for strategic decision-making.

    Develop your eye for design

    It is hard to grow a business if website design and marketing materials are lagging behind. A CEO needs to know the basics of composition, color use, and typography to communicate their vision to designers and web-developers clearly. A leader needs to understand the difficulties that designers encounter and provide argumentative feedback.

    Understand IT security

    Understanding network security principles helps realize what must be in place in a secure network. When a manager can assess the financial risks accompanied with the usage of a vulnerable network, it becomes easier for managers from the IT department to get more funding for security.

    Learning new tech skills is beneficial for CEOs because new abilities help look at business processes from a different perspective. New skills help communicate with colleagues, understand needs and requirements, and ultimately be a better manager. Learning new tech skills is one of the best ways to stay on top of things and formulate your company’s growth strategy in a clear and efficient way.

     

    How to Start a Custom Software Enhancement Project?

    Custom software enhancement is often confused with custom software maintenance services, because the line between these two terms may seem blurred sometimes. You need to know that software enhancement includes advancements in features, platforms, performance, usability and design. Through enhancement your software application becomes faster, more efficient, more usable, more useful, and more desirable. It’s the next step in your software’s evolution, that’s why you need to know how to prioritize the changes.

    Step 1: Get an idea on where to start your custom software enhancement project at.

    Create a database of requested changes where users of your solution can offer what they wish to see in the upcoming version of your software. In addition to this, you can approach your most valuable clients/users and ask them directly what kind of new features they would like to add.
    Afterwards, ask the development team what kind of functionalities they would add.

    They may speak in favor of:

    Upgrading the software to be compatible with new database releases;
    Adding new statistical analysis and visualization tools;
    Adding a new tab to the dashboard;
    Improving the search function; etc.

    Step 2: Evaluate the information and take a decision.

    As with all business decisions, it’s a cost/benefit problem. What is the benefit of adding a feature? What will it cost (including the costs that will result from not adding the feature)? Calculate how much it will cost to add it.
    Tip: Usually the cost is calculated in hours that have to be spent by developers to develop a feature.

    Analyze the information you got from the users of your platform and identify those missing features that will have a tangible business impact on user experience. It makes no sense to add a feature from which only a few will benefit.

    At first, pick those features that have the most benefit for the smallest cost. Resources are often limited, while requirements and desires are not, that is why it is so important to prioritize correctly.

    An accurate estimation of a custom software enhancement project may be a herculean task. These questions will help you estimate the project:

    1. How will your existing solution be affected by modifications?
    2. Do you need to build the new feature from scratch or does something similar already exist in the system?
    3. Can you reuse the existing code?
    4. Will modifications require the testing of the whole system?
    5. How many developers are needed to make modifications?
    6. How much time will it take to develop, design and test new features?

    The bad news is that you can miscalculate the time and effort required. For instance, the development of a new functionality might take longer than you expected and result in higher production costs.

    In order to avoid this kind of errors it is better to entrust your custom software enhancement project to an experienced team of software developers who know how to:

    • Thoroughly analyze existing software documentation
    • Analyze the architecture of the existing software application and offer structural changes
    • Analyze and make changes to the existing code
    • Perform software security analysis

    Custom software enhancement cannot be made by a low-skilled developer. That’s why you need someone who has experience in adding new features to a code written by someone else, who can understand not only how to build in new functionalities, but also to see the business essence of the system.

    One of the most important things in software enhancement projects is to clearly prioritize the requirements and take an approach to incrementally work on one function or feature at a time. Your users will thank you for the changes they’ve asked and waited for.