Your "Dessert"​ For a Sprint

Owned by Aleksandr Bogush
Mar 03, 2023
3 min read

Developer: “I’m done with the sprint scope, what should I do next?”. This sounds like a good thing, but it hides dangers to your workforce planning and reputation.

 

Do you ever find yourself in a situation where a developer has completed all of the tasks for current sprint and needs more work? What do you usually do in this case? Maybe you suggest they look into some tech debt or bug? Or you check Jira or a similar system to find a small but useful story, only to be told by the Business Analyst that it is not ready yet and you have to find something else? But the more the developer waits, the sillier you appear, so you probably tell them to find some bug to fix.

 

You may hear people say that it is okay to assign a bug or tech debt to a developer in this situation, but experienced project managers would disagree. This decision impacts the Value Stream Mapping – distribution of workforce between features, defects, and debts. This particular assignment to fix the small bug is driven by a lack of proper workforce planning, not a strategy to improve quality. To make the most effective use of team’s time, it is important to have the freedom to make conscious decisions, otherwise the money will be spent inaccurately. Also, little flaws like this tend to sum up and the team ends up missing deadlines on features, while far exceeding target quality level.

 

Establishing a Definition Of Ready (DOR) criteria is the best way to ensure teams never have difficulty finding a "dessert" for a sprint.

Rule 1: The criteria must be a JQL query or equivalent in your task tracking system. The query, not just the words in your knowledge base!

Rule 2: The Ready For Development (RFD) tasks should be readily available in the Backlog. Though this rule sounds simple, teams are often guilty of three mistakes: including the status of the task, expecting an assignee or marking RFD tasks manually with labels. A ready task is one that can be taken from the Backlog by any matching professional without any long communication between BA, QA, Devs, Scrum Masters, and Project Managers.

 

Typical Rules for Definition of Ready (DOR) are something like:

  • Description and Acceptance Criteria are not empty (or even contain certain keywords)

  • Estimation is specified

  • Task has subtasks for FE, BE, Testing, Test Cases (if applicable)

And since it is expressed as a query, you can add ordering by priority descending and estimation ascending. Save it as a filter and instruct your team to use it in the case when they need some “dessert” in the sprint.

 

To measure if there are enough tasks, use the metric Backlog Health. This measures the amount of Ready For Development tasks in the Backlog in relation to the average velocity. This works for both Scrum (using Average Velocity By Sprints) and Kanban (using Average Velocity By Weeks).

 

For a two-week sprint, Backlog Health can be categorized as follows:

  • Less than 1 Sprint (or 2 weeks): Red - Bad, team is at risk of not having enough tasks.

  • Between 1 and 2 Sprints (2-4 weeks): Amber - Acceptable, but not optimal. Not enough variety to fill the sprint without gaps.

  • Between 2 and 5 Sprints (4-10 weeks): Green - Optimal, typically enough variety and no problems finding RFD tasks of any size.

  • Over 5 Sprints (10 weeks): Amber - Not optimal, too much RFD tasks is a BA/Dev overhead. Such old tasks are guaranteed to be changed, requiring re-refinement and re-estimation.

 

Also, make sure there are enough small stories prepared, not just large ones. Remember, it's important to maintain control over the value stream distribution. Decisions to fix bugs instead of implementing stories should be deliberate, NOT dictated by circumstances.