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 Probability and Impact of an event/risk that might happen in the future, having a positive or negative result.
Grooming or Refinement meeting is a meeting where we prioritize all items in Backlog from those which brings maximum value. To make it happens, we use different techniques for prioritization:
- 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.
- 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.
- 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:
- Planning Poker
- Fist of Five
- T-Shirts Size
- Bucket System
- Points for Cost Estimation
But mostly, we are using:
- Planning Poker
- Fist of Five
- 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.
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 Sprint Planning meeting should be divided into 2 parts :
- User Story Estimation and the
- 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.
(Pessimistic Time +(4* Most Likely)+ Optimistic Time) / 6
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:
(Pessimistic Time – Optimistic Time) / 6
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.
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.