TL;DR
To gain the benefit of the TFB/NFC/1 technique, defer refinement to the last responsible moment. The team decides whether to refine TFB/NFC items on the Product Backlog or during Sprint Planning, but for Scrum it should be sooner rather than later. In Scrum, the work will typically need to be refined no later than Sprint Planning in order to build a meaningful Sprint Backlog, but will often need to be even sooner to support Backlog Refinement and agile release planning.
When to Refine TFB/NFC Items
You ask whether such items should be refined during Sprint Planning or Backlog Refinement. The answer is "either or both." The technique aims to:
- Reduce the overhead inherent in detailed estimation.
- Prevent work from overflowing the time box.
- Deferring refinement to the last responsible moment.
Deciding when to address specific items should therefore follow the agile principle of "maximizing the work not done." Don't refine it unless you have to, or until you need to. This makes it more of an art than a science.
Using TFB/NFC/1 by Itself
The goal of the technique is to ensure that no single item is bigger than a one iteration, but it doesn't help you to determine how many such items will fit into a single iteration.
In Scrum, the sum of all work should be less than or equal to the expected capacity of the Sprint. So, work that's TFB or NFC can't be accepted into the Sprint as-is. Instead, it should be treated like any other epic or story that is too large or too undefined: refined, spiked, or postponed.
For Scrum in particular, this estimation technique is most often a first-approximation tool, not a fine-grained tool for Sprint Planning. Even if all your estimates are 1, how many of those backlog items will fit into the upcoming Sprint? In a flow framework like Kanban this would matter less, but the unit of work in Scrum is the Sprint Goal, so you'd at least need to select enough 1 items to achieve that Sprint Goal without overcommitting.
You could achieve that without detailed estimates by selecting just enough 1 items to meet the Sprint Goal, and then validating that you haven't selected too much work by estimating the entire Sprint Backlog as a single unit using TFB/NFC/1. In other words, ask:
Can all the selected work be delivered within a single Sprint? Is it too big? Or do we have no clue whether or not we can deliver this increment as planned?
Measuring Confidence in a TFB/NFC/1 Sprint Plan
When looking at the feasibility of a single-Sprint forecast, the fist-to-five voting technique can help build consensus around the forecast built by selecting 1 items from the Product Backlog. With a scale of six, fist-to-five is a more granular way to measure confidence in the Sprint Plan than the TFB/NFC/1 scale, but still avoids the necessity of applying an entirely different estimation technique (like story points) to individual backlog items.
Mixed Estimation Techniques
Alternatively, a mixed-estimation technique that uses TFB/NFC/1 for Backlog Refinement or epics management, and a finer-grained technique like story points for Sprint Planning, might be more useful in Scrum. Because Sprint Planning is often a knapsack exercise where the Sprint length and Sprint Goal define the dimensions of the knapsack, you need a more granular metric than TFB/NFC/1 to optimize your packing. This is the problem that story points and velocity solve for, and which the NoEstimates movement would like to ignore. For example, whenever work comes scope for release or Sprint planning:
- An item that's TFB should be decomposed into INVEST stories that fit within a single Sprint.
- An item that's NFC should generate story spikes or other validated learning ahead of inclusion into a Sprint Goal.
- An item that's 1 should be decomposed into tasks of less than one in-Sprint cycle (e.g. the time between Daily Scrums) to meet INVEST criteria and control for Parkinson's Law.
By splitting the estimation techniques along functional lines such as epic management and Sprint Planning, you may reduce overhead related to developing fine-grained estimates for the Product Backlog and reduce time spent in Backlog Refinement meetings. This can sometimes be a valuable win, especially if refinement meetings run long for your team. However, it also makes it harder to do agile release planning when Product Backlog items don't share the same scale, or when the scale can't be measured in cycles.
For this reason alone, I often recommend using TFB/NFC/1 as a bucket-sorting technique for epics and large stories, but not as a full-fledged alternative to story points or ideal-hour estimates. It represents a trade-off in speed-of-estimation vs. granularity/accuracy, and is often most useful when trying to quickly sort coarse-grained items at scale. Once sorted into buckets, it's then a team decision whether to refine on the Product Backlog (to aid release planning and other schedule/budget estimates) or during Sprint Planning. In Scrum, the work will typically need to be refined no later than Sprint Planning in order to build a meaningful Sprint Backlog, but may not need to be refined further in Kanban if all work items are within a standard deviation of the same size.
There's a reason user stories rule the roost in most agile implementations. That doesn't make TFC/NFC/1 a bad technique; it just doesn't often fit the broader objectives of backlog estimation once you start getting down to brass tacks in time-boxing frameworks like Scrum.
