Story points or number of stories

Question

I feel that many of the estimates that the team provides during sprint planning are very large and they are reluctant to break stories down as they’re just itching to get out of the meeting and start coding. I know this is the wrong behaviour and it is leading to unfinished work.

While I am trying to address this in the retrospectives with the team, I was wondering if instead of measuring velocity using story points, we used the number of stories. Would that encourage the team to break down work into more stories? Has anyone used this approach, and what has been your experience?

Answer 1

A very interesting question with many facets. Why are the team reluctant to break work down before starting? why is estimation not working for you ? why are the team focussed on building stuff without understanding what they're building? how does this actually reflect in terms of work and indeed value delivered to the end customer?

I would start by looking at how closely customer outcomes are tied to the work you are doing and how well this is understood by the team. This might mean getting customers in, or at least getting someone from the front line in to speak to the team - this could be someone from customer services or the sales team.

Perhaps, the process for breaking work down isn't right, I would recommend looking at BDD. BDD encourages deep exploration of the problem space before exploration of the solution space - something I have seen many team struggle with. Often I see Product Owners, Product Managers and Engineering Managers talk more about how things should be done rather than what needs to be done in detail - and this will naturally put the development team on the defensive as they are not being allowed to be creative within their realm of expertise.

I actually think measuring the number of stories instead of the size of stories is a great way to go but I feel you have other problems to solve before you get there.

Lastly, sprint planning is not really possible without good backlog refinement which needs to be supported by deep dives such as 3 amigos meetings.

So in summary

1. Consider how well customer value is understood by the team, get someone in to talk to the team.
2. Look at how much time the problem space is given using principles from BDD.
3. Ensure you are having backlog refinement regularly and 3 amigos meetings for particularly technical requirements and big changes.

Hope that helps.

Answer 2

TL;DR

You may have an X/Y problem where the symptom is Developers failing to see value in collaborative Sprint Planning. However, the root cause is more likely a disincentive for the Developers to collaborate on a goal-driven Sprint Backlog together.

Analysis and Recommendations

Print Planning and the Sprint Backlog Require a Common Goal

I know this is the wrong behaviour and it is leading to unfinished work.

This is likely a symptom rather than the actual root cause. Based on things you've said and haven't said, it seems likely that the Sprint Backlog coming out of Sprint Planning is lacking a Sprint Goal. A Sprint Goal is required by the Scrum framework, and is what encourages the Developers to collaborate on building a Sprint Backlog rather than "itching to get to work" on their independent tasks.

Incomplete Sprint Goals Imply a Lack of Central Coherence

In addition, "unfinished work" isn't inherently a problem, but it's often emblematic of a team that's focused on "doing all the things" rather than achieving a coherent Sprint Goal. CodeGnome's Scrum Tautology℠ says:

Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.

Also, consider that you can have a successful Sprint that delivers the Sprint Goal even if you don't complete 100% of the items on the Sprint Backlog. See the next section.

Refine or Redefine What a Successful Sprint Should Look Like

Sprints can be considered successful if they leads to validated learning or process improvement, even if the Sprint Goal isn't met 100% of the time. You may therefore want to discuss the following with the whole team:

1. What the Definition of Done is for a Sprint.
2. What a realistic percentage of successful Sprint goal deliveries might be. Pro tip: 80% is a good starting point that isn't unrealistic or unachievable, but you can refine it as the process maturity improves.
3. Generally revisit what a successful Scrum implementation means for your Scrum Team, the project, and the organization.

In short, move away from 100% completion or 100% utilization as your metric for success. That will provide more incentives for collaboration, and reduce incentives for independent or unplanned work.

Refocus on a Collaborative Sprint Goal

By focusing on the Sprint Goal at the Scrum Team level, rather than defining productivity at the individual Developer level, you will likely reduce the number of unsuccessful Sprint Goal deliveries. This should also reduce the incentives for the Developers to focus on their own work at the expense of the Scrum Team's overall success.

When the Developers see that the plan in the Sprint Backlog requires collaboration between them, they are much more likely to:

1. Decompose user stories or Product Backlog item into tasks that can fit within a single Sprint. NB: This is closely related but not identical to the next item.
2. Discuss implementation details of Sprint Backlog items to right-size the Definition of Done for all planned work items in a way that helps them fit within a single iteration while still meeting the unified Sprint Goal.
3. Build a plan together rather than being incentivized to get to work independently as quickly as possible.

Without that shared understanding of how and why their work fits together, it's hard to see why the Developers would be incentivized to collaborate on a plan. So, building that understanding is foundational to changing the negative outcomes you're collectively experiencing.

See Also

• Why must we define a Sprint Goal for each Sprint?
• If we can’t finish all tasks, does this mean we are doing Scrum wrong?

Answer 3

You should go with story point only, if the dev team is reluctant then you should take a reference of previous done stories.

IMO- I never go with Story estimation into the story points.

Answer 4

The problem that I see here isn't one related estimation technique. The main problem that I see is the lack of investment in refinement activities. Planning is not the time to work on understanding, detailing, decomposing, and estimating work. If you try to refine and plan in one session, I can see how that can be grueling for the developers and they can lose focus in the meeting.

Going into your planning session, you should have sufficient work on the backlog that is well-refined. Although what it means to be well-refined varies by context and team, it means that the team has enough of an understanding of what is needed to carry out the work and they have confidence that the work can be completed within a timeframe. For example, the Scrum framework uses refinement to ensure that any individual Product Backlog Item is something that can be completed by the team within one Sprint. In my experience, many teams try to make the units of work smaller, often something that can be completed within a few days.

There are many ways to carry out refinement, and there are plenty of questions and discussions in various places about options that teams have had success with. You can experiment with these different techniques to see what works best for the team. However, you should see that if you keep enough of your backlog refined, you can focus more on figuring out what the team is capable of doing and how to do it at your planning event.

You may still want to evaluate the use of story points versus other estimation techniques, even no estimate techniques. If you do choose to estimate, then estimating the work would be part of your refinement activities and done before planning.

I'd also add that you may not be able to eliminate refinement from your planning session. Your reviews with key stakeholders may result in changes to your backlog. These changes may lead to unrefined work being added or moved up in ordering in the backlog, which means that the team will need to do some refinement between the review and the end of the planning session.

Answer 5

Put in the skin of the devs... what are they going to get by putting the effort into estimating a task? NONE.

Forcing them to do it is a bad idea and making them accountable for the estimates is even worse, so...

How do we do it then?

First, you need to provide an incentive to the devs to come up with an estimate. The incentive could be economic, they might have some free time to play, remember the goal isn't an objective for the devs, but it is for the company... no one likes routine... as devs within scrum we want to celebrate successes, we want to iterate and see how our babe is growing, we want to make sure everyone is doing their best. Going every day from 9 to 5 expecting people to have that enthusiasm is not going to work... no if you want to get the most out of them... as any other creature on this planet we move by incentives...

What's the technique?

Ask any dev on the team to describe what he/she would do to accomplish the task. Every sentence is a task! Once you have all the tasks down ask the next dev, do you agree? The next dev will help you out with more refinement, deleting, moving, renaming, etc... tasks. Once all devs have spoken, it is time to estimate. Make sure everyone says an estimate, remember, we are using complexity points no time! Once the estimation is finished... grab the tasks that are big and repeat the process again. Once the meeting ends you should have enough work to do for the sprint. Remember to make sure the goal is achievable before finishing the meeting. Make sure the team keeps refining tasks with the product owner as they move through the sprint getting to the most unknown tasks.