An agile workflow allows groups to estimate new work effectively. A group that has been working together for some time can estimate new user stories much better. Groups that have experienced failures and successes in the past can compare their speed against point estimates that all members can accept and thus, they can predict with rational accuracy how hard it will be for them to complete new stories.
Groups that are new to agile workflow, however, may find it hard to determine how to estimate user stories effectively. Some teams find that the soft relationship between actual time allotted working on stories and point value can be disrupting. Others find the team-specific and abstract concept of points hard to understand. Attempts to get precise point estimates for new user stories may feel loose and obstructive. There are agile estimation techniques that can be used to make the process easier for groups. One of these is TFB / NFC / 1 (Sprint). This technique can get every member of the group involved in productive point estimation from the beginning, no matter their level of experience or skill with agile techniques might be.
How Does TFB / NFC / 1 (Sprint) Work?
TFB / NFC / 1 (Sprint) is an agile estimation technique similar to Big/Uncertain/Small, another agile estimation technique that places items in one of the 3 categories – Big, Uncertain and Small. With TFB / NFC / 1 (Sprint), on the other hand, there’s a specific size in the mix and that is 1 Sprint. The categories include No F-ing Clue, “1” Sprint and Too F-ing Big.
Why Use TFB / NFC / 1 (Sprint)?
TFB / NFC / 1 (Sprint) is fast. A large number of items can be estimated within a short period of time. It is also collaborative, so each member of the team can participate roughly equally. The right people participate in the estimation process. Tracing who estimated what is impossible, so group accountability is promoted. If someone makes an incorrect estimate, there’s no way to know this person. The whole group is responsible for everything, so no one can blame any member of the team.
This agile estimation method also gives relative results. You’re not really trying to learn to foresee the future. Agile estimation techniques like TFB / NFC / 1 (Sprint) help you realize that the estimation process is a non-value added activity and reduce it as much as possible. Most agile estimation methods also use relative units. This means that teams don’t have to estimate days or dollars directly. Qualitative labels or points are instead used and items to be estimated are simply compared to one another. This uses a person’s ability to compare things to one another and prevents difficulty in comparing items to an intangible matter such as days or dollars. It is important that teams learn how to approach new user stories and determine the amount of effort each story will take to complete. With TFB / NFC / 1 (Sprint), estimation is made much simpler.

— Slimane Zouggari

Adopting an Agile workflow allows teams to estimate work more effectively. New user stories will come and team members should develop a progressively precise sense of how they are going to approach these stories and how much effort the user stories will take to complete. Everyone on the team should participate in the estimating process to arrive at a precise estimate that reflects the team’s true investment and understanding. The team’s ability as a whole to estimate new user stories will develop slowly if members don’t participate actively. Divide until Maximum Size or Less is an agile estimation technique that teams can use when estimating new user stories.
How Divide until Maximum Size or Less Works
The team chooses a maximum size for all the items. Every item is discussed by the team to decide if it’s already that size or less. In case the item is bigger than the maximum size, the team divides the team into sub-items. They then repeat the process with each sub-item. This will continue until each item is in the acceptable size range.
Benefits of Divide until Maximum Size or Less
Divide until Maximum Size or Less is a collaborative technique. All members of the team are included in the estimation process, so blaming someone is impossible as there’s no way to trace the member who made an estimate. As such, the group is responsible as a whole. Since everyone is liable, every member of the team will be more encouraged to participate in discussions and give an estimate.
Since Divide until Maximum Size or Less is an agile estimation technique, it is faster than traditional techniques. Members don’t need to spend all their time estimating user stories using time-consuming methods and they can focus more on their work. Team members don’t try to estimate days or dollars directly. Points or qualitative labels are instead used and the items the group is estimating are compared to each other. With this, members of the team don’t need to compare something to an intangible concept.
There are other agile estimation techniques that teams can use aside from Divide until Maximum Size or Less. One of these is Planning Poker where team members vote for an item estimate using individually-numbered playing cards. Voting is done repeatedly until the votes are the same. The Bucket System is another agile estimation technique. It uses the same order as Planning Poker. Items are estimated by putting them in buckets. Compared to Planning Poker, The Bucket System is faster since there’s a divide-and-conquer step. It can be used with bigger groups as well. The Bucket System can be used to estimate large numbers of items.
By using these agile estimation techniques, a group that has no previous idea of point values can understand the relative value of the stories they encounter. The sooner the team begins estimating points and monitoring their efforts, the more effective their point valuations will become. Every member of the team will eventually become more proficient at estimating new user stories.

— Slimane Zouggari

While Planning Poker can help you bring up the conversation for user stories, it’s not really the most effective way of estimating those. In Planning Poker, participants vote for an item estimate using specially-numbered playing cards. Voting is done again and again until all votes are the same. This process is certainly time-consuming, but there’s a better way to arrive at an estimate of an item. Challenge, Estimate or Override or the CEO game is a more effective estimation method and is suitable for agile environments. You can use the CEO game to lessen the amount of time spent on estimation of user story and focus more on collaboration. Here’s how to do the CEO game.
• Print out user stories as cards.
• Gather everyone around a long table.
• The top of the table should show stories that are estimated the biggest and the bottom of the table should display stories that are projected the smallest.
• Every participant should read a card and estimate it by putting it on the table. The lower the cards are placed, the smaller they are. This step is called Estimate. Get a card that’s already placed on the table and move it on the same table. This stage is referred to as Override. Take a card and challenge the participant who placed it on the table on their estimate. This step is called Challenge. It is the participant’s responsibility to argue on his estimate and then correct it.
• Participants should take turn following the rules stated above until there’s no card to put on the table.
• When there’s no longer any card to place on the table, participants can get one last chance to play the CEO game if they want.
What to Remember When Playing the CEO Game
The Challenge option can only be used once every 2 turns. This option is most beneficial when a participant doesn’t agree with the estimate and he doesn’t know who made the estimation. You can also ask the members of the group to stand during the entire process. If you don’t do this, they may lean and be inactive when placing the cards.
Once the exercise is completed, Fibonacci numbers can be assigned to the user stories if desired. Fibonacci numbers can start with 1 and 2 and followed by the sum of the 2 previous numbers. For instance, it can go like this – 1, 2, 3, 5 and so on. 2+1 is equal to 3 and 5 + 3 is equal to 8.
Participants can also choose to only Override or Challenge two times, so they don’t get overwhelmed and they can choose their battles. You now have a list of user stories estimated within a shorter period of time. If you’re using an electronic board, try to use a projector if some participants don’t agree with the terms of user stories and you’d like to see them. Any concerns or questions about a user story can be explained by discussing it more carefully.

— Slimane Zouggari

The Bucket System is all about estimating large amounts of items with small and medium sized groups and doing it fast. It is ideal for agile environments because it is collaborative, fast and gives relative results. You can estimate hundreds of items within an hour and everyone in the group can participate roughly equally. Since the results cannot be traced to any individual, this system promotes group accountability. You can work with stakeholders to predict value or collaborate with teams to estimate effort.
How the Bucket System Works
1. Use the diagram below to create the physical environment and make sure that all the items you need to estimate are written on cards.
2. Pick an item randomly from the collection and read it to your group. Put it in the 8 bucket. It will be the first reference item.
3. Select another item randomly from the collection and read it. The item’s relative place on the scale will be discussed by the group. The item will be placed in the right bucket once consensus is achieved.
4. Pick a third item randomly. Again, the group will discuss it and the item will be placed in the right bucket once consensus is attained.
5. The items can be re-scaled in case they have tilted the scale to one end.
6. Assign the remaining items equally to all members of the group. Every member puts items on the scale without discussing with other members. If a member has an item that he doesn’t understand, that item can be given to another person.
7. Every member must quietly evaluate the items placed on the scale. If someone finds an item that he thinks should not be there, he can discuss it with the group. The group will discuss it until they reach a consensus and the item is placed in the right bucket.
8. Record the estimates by writing the bucket numbers on your cards.
Things to Consider when Using the Bucket System
There are some things that you should consider when using the Bucket System. One of these is that you can place several items in the same bucket. Placing items between buckets is prohibited. If the item distribution is titled to one side of the scale or the other, the group should discuss during the “sanity check” if the items should and can be distributed more consistently along the scale. If it is possible, the group can do it together.
The facilitator should also observe to ensure that nobody moves any item that has already been placed until the sanity check is done. The distribution of items among group members doesn’t need to be precisely equal. You can distribute the items roughly.
If one or two members are working sluggishly through their items, they can share the remaining items with those who are already done. It’s not acceptable for any member to completely withdraw from the process. Someone who wants to abstain from the process should be counselled. This means he won’t have any say in the estimates in the future. Absolute silence should be maintained during the divide and conquer step. There should be no mutual discussions of items to protect the privacy of members placing items.

— Slimane Zouggari

Big/Uncertain/Small is an agile estimation method where the items to be estimated are placed by the group in any of these categories – big, uncertain and small. Teams discuss a few items together and then uses divide-and-conquer to estimate the remaining items. Big/Uncertain/Small is just like the Bucket System. In the divide-and-conquer step, you allocate the remaining items to all members of the team. Every member puts items on the scale without discussing it with other team members. If someone has an item that he doesn’t really understand, that item can be given to someone else.
Benefits of Big/Uncertain/Small
Big/Uncertain/Small is designed to be collaborative. This means that everyone in the team contributes roughly equally. The results cannot be traced to one person, so this agile estimation method promotes group accountability. Even if someone makes the wrong estimate, that person cannot be determined. No one will know what his estimation was. Blaming someone in the team when something goes wrong is avoided. Since the method is collaborative, all the right people participate in the estimation process. No team member can give any excuse and escape from the responsibility of taking part in the process of estimation. Everyone in the team needs to work together.
This agile estimation method also takes advantage of people’s ability to compare things and helps teams avoid comparing items to abstract concepts. As such, the estimation process is simpler and can be completed much faster. Teams don’t need to use old-fashioned techniques that will take so much of their time. With Big/Uncertain/Small, they can save time and focus more on collaboration.
Big/Uncertain/Small is similar to TFB / NFC / 1 (Sprint). However, TFB / NFC / 1 (Sprint) includes a specific size and that’s 1 Sprint. The categories in TFB / NFC / 1 (Sprint) are “1” Sprint, Too F-ing Big and No F-ing Clue.
There are other agile estimation methods that teams can use aside from Big/Uncertain/Small. One of these is Affinity Mapping where items are assembled by similarity. This similarity is usually a physical activity and needs a small number of items. The groups are linked to numerical estimates if preferred.
Another agile estimation method is T-Shirt Sizes. Items are grouped into t-shirt sizes – S, XS, M, L and XL. If required, the sizes can be given numerical values once the estimation is completed. This method can be used with a large number of items. The decision about the size is usually based on open, collective discussion. By using an agile workflow, the team can estimate new work more effectively.
As they face new stories, they will have a more precise sense of how they should treat each user story. They will also know the amount of effort they need to spend on each story to complete it. A group that has been working together for some time can estimate new stories much better. Agile estimation methods can get all members of the team involved in productive estimation regardless of their experience level with agile methods.

— Slimane Zouggari

Affinity mapping is used to group and understand information. It is a good way of identifying and analysing issues. Affinity mapping can be used in agile or workshop environment where participants need to work together to identify, discuss and group issues.
How is Affinity Mapping Done?
Affinity diagramming involves putting related items together. Small sets of data can be placed together electronically, but it’s still better to do it on paper. Using paper is advised in group situations. Items are gathered by similarity and this similarity has to be estimated. It’s usually a physical activity and needs a small number of items. The groupings are linked to a numerical estimate if preferred.
If there’s a pre-existing set of data, you can print these on cards or labels or paper and cut them to the right size. In group situations, post-it notes can be given to members. You can ask your group members to write one issue on every note. Give members some time to do this, but you should ask them to stop when most of the participants have stopped.
Call all participants and assemble at a vertical surface appropriate for post-it notes. Encourage everyone to put their notes on the surface one at a time. As every note is placed, other members may add related notes nearby. Depending on group dynamics, data being examined and amount of time, spending some extra time considering and reorganising the groups may be necessary. Once all notes have been gathered, you can name every group. This step is optional.
If the number of participants is more than eight, it may not be very convenient to gather around a common area. You can place all the notes on your own and get one note from every participant in turn. All of them can then give you any related notes. This may not be as suitable as getting the group to work together. This is because keeping everyone focused on the activity can be difficult. Affinity mapping is certainly a great tool if the result of the activity can be followed up fast. For instance, with affinity mapping, the group can discuss methods to address and solve various issues.
Things to Keep In Mind
If you’re managing the activity, you should always pay attention or you may not know what’s happening and it will be hard for you to understand the data structure. All group members should also be allowed to contribute. There may be a person who wants to control the positioning and move the notes. Don’t let this happen. Never move anybody’s note without their consent or agreement. Discussion with group members will often mean that someone wanted to bring up a different matter. You should encourage all members to put one note at a time and read them aloud.
Affinity mapping can also be exhausting. Don’t let the activity go beyond the point of boredom or exhaustion. There should be no more than two successive affinity mapping assemblies during a workshop. Since the resultant groupings are random, you should be flexible in the way you use information.

— Slimane Zouggari

Have you ever heard the term “story points”? Well, it is simply a subjective tool used to measure a feature’s size in relation to other features. In addition, this arbitrary measure is commonly used by Scrum teams to identify the points where the feature has its complexity. This is composed of numbers that ranges from 1, 2, 4, 8, 16, or extra small, small, medium, large and extra-large that is used in the estimation of the project’s features. Thus, the most commonly used series in here is the Fibonacci sequence ( 1,2,3,5,8,3,21,34,45).
Moreover, the main importance of story points is that it enables various team to communicate about a certain level or degree on an estimate. This is very much essential for it avoids the conflict that may arise because two opposing programmers have different skills and way of thinking. It actually serves as a unifying mechanism that makes two exactly different estimation of programmers jive and agree with one another.
Since there’s a lot of issues involved in the conventional techniques of having an estimation, still, a lot of team members are trying their best to give an immediate yet accurate estimate in all their projects. For example, in the work field, stakeholders will definitely ask you to deliver your finished projects or even an outline of it with agility for they also need to meet a deadline of the reports of the development of the project. So, to provide a quick solution on this matter, the team discovered a new technique of providing immediate and accurate estimate that will absolutely help you make a right and agile estimate about the detailed features of the project.
Using story point is truly effective for it will not require you to spend long hours just to analyze and make an estimate on the features. Even though you don’t have a wide array of information to estimate the time in creating the framework, still, you can quickly compare the sizes of one feature to another, the same thing goes in estimating the buildings. You can also compare its sizes towards the others for you to make an estimate on how many days will it take for the workers and developers to construct it. The sizes of the building itself can be converted to number through the use of an estimation scale, and here is where the Fibonacci scale works. It provides enough separation between the numbers for the team to avoid confusion over slight differences among the estimates. Thus, through this, the team can easily come up with more precise and accurate estimates.
Using a story point is really different from those classic estimation technique for while they examine and analyze the major word tasks to make an estimate, with SP, the team does not need to examine the task but rather, they only need to compare the sizes and complexity of the project features. Thus, for the team to provide a correct estimate, they use a planning poker wherein a customer or a product owner leads a discussion of the feature, and after that, a question and answer portion is conducted. After the conversation is completed, all the members can hold up the index with their estimates now. If everyone voted for same number, then it’s done. The estimate is already official and recorded. That’s how story points works.

— Slimane Zouggari

T-shirt sizes in product backlog? This is the most common question that people have in the mind, especially those who are curious on how programmers create a software and make an estimate to product backlogs quickly. Since you don’t want to waste time waiting for results for so long just for product backlog estimates, the team now has developed another technique in achieving a consensus of what will be the final estimates of that certain product or item. Thus, this T-shirt sizing in agile is found as an efficient tool in coming up with an agreeable and reliable product estimation. Now, what is really the use of the strategy “T-shirt sizing?
T-shirt sizing is an effective way of knowing a particular product size. By comparing its features, you can break it into different sizes such extra-large, large, medium, small and extra small. Estimating through tis relative sizes or buckets are far better than making an estimate based on absolute effort or time. Nobody wants to waste time thinking and estimating. Also, it will just turn into a disappointment if it happens to be a false precision.
Procedure
• In starting with t-shirt sizes in agile, each backlog item or product should written first on a 3×5 index card and be placed on a table before anything else.
• Choose the smallest sized product that will serve as your point of reference
• Organize and group the cards with its corresponding sizes approximately 2x as big as the first one, (M = S + S , L= M+M). Items having sizes larger than XL is an epic for it too big to estimate.
• Once all of the items are organized and placed to their groups, points will be assigned to each size. You can use the Fibonacci series to make the estimate more precise.
Pros
• T-shirt sizing is a much easier way to get started with your product estimation. It is much accessible and convenient to use than other techniques that requires a great time just for the team to arrive with a final estimate of the product features or item. As the team uses this T-shirt in agile, they become more accustomed to having a relative estimating. Starting with T-shirt sizes is not necessarily wrong but incorporating underlying numbers on each of it will make a better result and accurate estimation
Cons
• They are not additive. In a formal context, you cannot use its terms in giving an estimation on a product. You may even sound funny if you are going to tell your manager that your work will be done in 4 mediums, 6 larges and 3 petites.
• The view of an extra-large size may vary and not match on your boss. You cannot say that the product is 25% bigger than a large size or the large size is 50% bigger than small size for it’s so confusing. Thus, it cannot be applied to a large scaled items for definitely, you will find it hard to make an estimation out of it.
Truly, there are a lots of ways on how you can make an estimate on products backlogs or item. T-shirt sizes in agile is just one of the numerous methods. Which strategy or technique to be used depends already to the team. What is more important is that the outcome of that strategy should provide precise and accurate estimate of the item to avoid conflicts with your manager or stakeholders.

— Slimane Zouggari