0

So, I'm very junior and am wanting to learn PM stuff, and I'm encountering a strange issue in my team.

We want to use velocity as a way to see whether we're improving or not. However, my understanding is velocity is based off of PBIs, not tasks. This make sense since we're measuring deliverable work.

I don't know if this is just a fault of the way we're doing it but our PBIs are huge. Essentially, our epics are split into features, but most of the time, the feature has 1 PBI which is just an inclusion of all the work needed for the feature.

It's not uncommon that these PBIs have 20 tasks or so. Some tasks are small and only take a few hours, whereas some take many many man-days. It's not uncommon that in total the work required to complete a PBI is therefore hundreds of man hours, and so sometimes, the team works and completes a lot during a sprint, but because we couldn't definitely close the PBI during the sprint, it counts as 0 towards our velocity.

So what's the issue here? Are our PBIs too big? Can we just not use velocity as a metric like this?

I just don't know how we'd split the PBIs any more, since we can't just, for example, ship untested work... It seems like the answer is 'split them smaller or don't use velocity in that way' but I'd like to hear the opinions of others.

Edit: To be clear, the framework is scrum, but it seems to be very loosely followed. I suppose the word 'agile' is kind of just thrown around, with only the scrum master ever specifically mentioning following scrum guidelines.

1
  • "Velocity" is a measure of capacity and helps you figure out how long it takes to be "done." Since agility is a set of principles, not a framework, I have no idea what you think a PBI should look like, but in general it should be a vertical slice of value delivered in short iterations. There's probably a lot wrong with your tooling and implementation of whatever framework you're using, but you need to expand on what that framework is, why your PBIs are so large, and why your teams are unable to split them. Without that, we're just guessing at your possible dysfunctions. 🤷‍♂️
    – Todd A. Jacobs
    Aug 9, 2023 at 3:00

5 Answers 5

1

Your last sentence already hints at the answer: If your PBIs can not be completed within a sprint, they are too big, and you can't use them to compute velocity.

So the first step should be to work on refining backlog items so that the resulting items are small enough to be completed within a sprint. You should not have one big item that fills the sprint's capacity, but enough smaller ones so that even if your team can't complete some item it can still complete enough to meaningfully achieve the sprint goal.

Of course you should not split backlog items into "implementation" and "testing" so you would have an untested intermediate result. Instead the scope of each item should be small enough (and well-defined) such that its complete implementation, test and integration can be done within the sprint.

6
  • So you don't think it make sense to split PBIs into design / code / test? I figured each step is still a concrete step towards the sprint goal of delivering a particular feature.
    – Yvain
    Aug 8, 2023 at 11:47
  • 1
    Results of a sprint should be finished increments. An increment is only finished when it is "done", which implies coded and tested. If a PBI is so large that designing, implementing and testing it can't fit in a sprint then it is too large. Aug 8, 2023 at 11:58
  • What would your response be in a hypothetical scenario where the smallest deliverable increment is actually truly incapable of being delivered in the course of a sprint? Would you just say Agile is not a compatible framework in this case? Or would you reject that that's even a possibility?
    – Yvain
    Aug 8, 2023 at 12:34
  • I can't speak from personal experience, but the Scrum authors seem to assume that it is always possible to break PBIs apart until they become manageable. I would be interested in a real counterexample, but this probably warrants a separate question. Aug 8, 2023 at 12:57
  • @Yvain There's no such framework as "agile." You need to update your question. Are you doing Scrum? Kanban? Lean? Amplio? SAFe? Nexus? Something else entirely? You'll get more useful answers if you provide more context.
    – Todd A. Jacobs
    Aug 9, 2023 at 3:02
1

TL;DR

Within the Scrum framework, work selected for the Sprint during Spring Planning must meet a number of criteria. To be a bit reductionist, when combined with other sections of the 2020 Scrum Guide such as the definition of the Product Backlog it is clear that work selected for the Sprint must be completable within a single iteration.

To do that, you'll need to avoid skipping over essential framework activities such as Backlog Refinement and setting Product and Sprint Goals. It is extremely common for new Scrum implementations to overlook the importance of these activities, and that is most likely where your difficulties start.

Analysis and Recommendations

Understanding Sprint Planning and Sprint Goals

In Scrum, Sprint Planning is an activity where the Developers select Product Backlog items (PBIs) that have been refined by the Scrum Team sufficiently to fit within a single Sprint.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal...When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.

There are certainly other criteria at work, but in general, the flow is:

  1. Product Goal defined on the Product Backlog

    The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against...The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

  2. A singular Sprint Goal is defined by the Scrum Team in order to make progress towards the current Product Goal through the delivery of one or more Increments. The guide says (emphasis mine):

    The Sprint Goal is the single objective for the Sprint...[that] provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

    Note that "[a]n Increment is a concrete stepping stone toward the Product Goal" so you can have more than one Increment per Sprint, but only one Sprint Goal. This is the most common thing people get wrong: not having a well-defined Sprint Goal that can reasonably be delivered by the end of the Sprint.

  3. Developers perform PBI selection from the Product Backlog, using the Product Goal, Sprint Goal, and team capacity as guides. Team capacity is the primary use of velocity, but "velocity" is not a required metric for the Scrum framework.

    • Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

    • Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

  4. Selected work is further refined by the Developers for the Sprint Backlog. While not mandated by Scrum, the work is often decomposed into user stories or vertical slices using the INVEST mnemonic.

    The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)...[that provides] a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.

  5. All PBIs not completed by the end of the Sprint are returned to the Product Backlog for future consideration. This last item has been hotly contested by people over the years, but the 2020 Scrum Guide (with emphasis mine) makes it very clear:

    • Work cannot be considered part of an Increment unless it meets the Definition of Done.

    • The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

    • If a Product Backlog item does not meet the Definition of Done...it returns to the Product Backlog for future consideration.

    This is necessary because agile frameworks embrace changing requirements, so incomplete work may or may not still have value. Even if it potentially has value, a given item may not remain aligned with the Product Goal or Sprint Goal for the next Sprint. Even when in scope, the PBI may need additional refinement and re-estimation based on the current state of the project and its objectives rather than on historical estimates. In short, the priority, objective, and level-of-effort for the incomplete PBI must be re-evaluated rather than simply "rolled over" to the next Sprint.

Confidence Intervals, Cadence, and Sizing

An effective Sprint delivers Increments of value. Ideally each Increment is a vertical slice of functionality, but can be anything the team determines can move the ball downfield towards the Product Goal. The objective of a Sprint is not to complete all the items on the Sprint Backlog, but to meet a unifying Sprint Goal.

Generally, the success of a Sprint has nothing to do with how many backlog items you perform. Instead, it's based on whether or not the Scrum Team collectively met its commitment to the Sprint Goal. This won't always happen, but if you're missing your Sprint Goals more than 20% of the time then you haven't developed a reliable delivery cadence.

Velocity with appropriate fudge factors can be a useful metric for determining whether the Scrum Team has enough capacity to meet the work needed for the current Sprint Goal. However, velocity is just a probability range based on various factors, and is not a money-back guarantee.

There are other estimation techniques that can be more useful when evaluating the overall size of the Sprint Backlog. Two of my favorites are:

  1. TFB/1/NFC

    • TFB: "too freakin' big" to fit into one iteration; such work should be refined further using INVEST or similar techniques
    • 1: likely to fit within a single iteration
    • NFC: "no freakin' clue" means the work isn't sufficiently decomposed, doesn't meet the team's Definition of Ready, or is otherwise inestimable and needs to be clarified or refined further
  2. Fist-to-Five

    Regardless of how the work was selected or sized, the Developers or the whole Scrum Team hold a "confidence vote" to determine how confident they are that the plan will successfully meet the Sprint Goal. This is usually done by polling the team, and on the count each team member holds up 0-5 fingers. The average is usually taken as the team's collective level of confidence in the Sprint Plan, which should be discussed or revised if the confidence level is too low.

Utilization rates or volume are not the objectives; instead, you are aiming for a reasonably reliable, sustainable delivery cadence for the team. If your Sprint Plan doesn't have a clear Product Goal or Sprint Goal, or if the Sprint Plan has insufficient slack to allow for normal variances, then you will continue to struggle with creating a sense of predictability for both the Scrum Team and other stakeholders.

Backlog Refinement

The Product Backlog should be routinely refined to ensure that PBIs are ready for selection. This is another area where your team is likely struggling.

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.

If your Scrum Team is entering Sprint Planning without sufficiently-refined PBIs that can fit within a single Sprint then you need to spend more time on Backlog Refinement in order to meet the "small" and "estimable" elements of INVEST. Even if you don't strictly follow INVEST, you must still ensure that the team has sufficient PBIs that are ready for selection, align with the current Product Goal, and form a coherent Sprint Goal. This can be hard at first, but gets easier with practice and when the team leverages the Sprint Retrospective to identify and improve on the processes that are leading to incomplete Sprint Goals.

Scrum is based on empiricism and validated learning, so there's definitely a learning curve involved in building the team's estimation and planning muscles. However, the framework provides a lot of inspect-and-adapt opportunities, and encourages continuous improvement. Just make sure you start with the essentials like refinement, Definitions of Ready & Done, and clear Product & Sprint Goals. Without those in place, you won't be gaining the benefits of the framework; you'll just be following your pre-Scrum processes and then wondering why things aren't fitting within the time boxes or incremental delivery model that Scrum requires for success.

0

If you have spillovers into the next sprint often, or you have hundred man hours PBIs in your sprint, or you have 20 tasks in a PBI, then your PBIs are most likely too big. You need to split them into smaller items.

Ideally, you should look for things that have the INVEST characteristics.

If you already noticed that this is a problem (and from here your post), raise it at your next retrospective and discuss it together with the team. Think how you could improve.

  • Maybe spend enough time on upfront refinement of items; your backlog should contain smaller and smaller items as you go towards the top.
  • Maybe the team could pay more attention at the sprint planning to better estimate if items fit in the sprint or everything is just a wishful thinking tight squeeze.
  • Maybe people should focus less on tasks and more on outcomes; vertical layers instead of horizontal layers.
  • Maybe more training is needed so team members understand what iterations and increments are all about.
  • Etc.

Whatever approach you choose, you will see that having smaller PBIs will help improve many aspects of your work, not just allow you to make use of velocity.

0

A PBI needs to be small enough to complete in one sprint. Don't split items into design, build and test components. Instead split the feature, deliverable or other outcome into smaller features, deliverables or outcomes. The aim should be to make each item a valuable deliverable in its own right.

Splitting backlog items is a skill that any Scrum team needs to develop. This is where regular backlog refinement activities (the "fifth ceremony" in Scrum) can help the team.

https://medium.com/the-liberators/10-powerful-strategies-for-breaking-down-user-stories-in-scrum-with-cheatsheet-2cd9aae7d0eb

0

It appears that your product backlog items are too large when they are selected into the sprint. The items that are near the top of the Product Backlog need splitting into smaller ones that are then suitable for inclusion into a Sprint Backlog. (More distant PBIs can remain as large items until they get nearer - this avoids the Product Backlog becoming huge and difficult to manage).

Your Scrum Master should be gathering the team for Backlog Refinement at least once per sprint, and a large part of that will involve breaking these upcoming features into smaller work items with clearer scope. If this isn't happening, ask your Scrum Master why not, and how this is expected to happen (remember that Refinement is a whole-team activity, where having many eyes on the stories can uncover mistaken assumptions, unanticipated dependencies, or unproven requirements, for example).


Splitting stories isn't always easy, and I empathise with your problem here:

I just don't know how we'd split the PBIs any more, since we can't just, for example, ship untested work

I agree that you mustn't split in such a way that verification gets separated from implementation work. In my team, a story cannot be Done if its testing or documentation is incomplete, and that's the case for any reasonable definition of Done.

Without knowledge of your problem domain, any advice is going to be very general. I work in software development, so my strategies for splitting stories include the following:

  • Is there some open-ended investigation that needs to happen before we can even plan how to implement the feature? If so, create an enabler story to do the investigation, without making any changes to the product. Its Definition of Done will include producing a written explanation with the findings and the recommendation for next steps.
  • Is there any low-level "plumbing" required before the user-visible feature can be implemented? Then we can have a ticket for the plumbing (unit-tested, and possibly integration tested using stub UI), and that's shippable even though nothing is making use of it yet.
  • Can we implement a subset of the functionality? For example, if we need a "search" function, could we start by making simple substring search, before extending it to accept regular expressions?
  • If necessary, use a Feature Toggle for an incomplete feature that should only be enabled by developers working on the feature, until it's ready for users. Prefer a run-time toggle to a compile-time #ifdef or equivalent, so that the partial code gets compiled and is available to the automated tests.

Again, this is a team activity, so all the developers should be asking these questions (and more) and coming up with creative proposals for possible splits. Even if an idea is impractical, it can often spark another developer's imagination, and that's the great value in having the full team together for Backlog Refinement.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.