Using story points at sub-tasks level to identify the team sprint velocity

Last post 09:08 am March 31, 2022
by Sharad Singh
5 replies
Author
Messages
08:07 pm March 29, 2022

Hi,

 

We are in the process of implementing the agile/scrum for the education development team. We have 3 weeks sprint cycle. The instructor designers develop training assets and these assets take more than one sprint to complete.

We are estimating the stories using story points at the story level, however, there are a few challenges we are facing with this approach.

  • As the team is unable to complete the story in a single sprint cycle therefore at the end of the sprint, we can't identify team velocity for the specific sprint.
  • The story represents a request for a single training course that can be broken into lessons or learning objectives but it doesn't make sense to create a story for each lesson/learning objective. Also, the course request can be broken into lessons post-planning phase only and that is the part of the development phase.
  • Also, we are using an iterative approach to develop the story (training course), therefore the first iteration can be only three lessons, the second iteration can be the next three lessons, and so on. The iterations are also captured as a part of the sub-task. Iterations can also be identified after the planning and analysis phases.
  • There are pre-defined sub-tasks that the team uses to track the progress. Each sub-task represents a development stage.
  • If the team starts to estimate the sub-task using story points, I think, we should be able to see the team velocity for the sprint based on the sub-tasks completed in the sprint.  

 

I know that we should not do the story point estimate at a sub-task level as it is not recommended, however, I am looking for any other innovative approach or solution to resolve this issue.

 

Thanks in advance. 

 

Regards

Sharad Singh

07:23 am March 30, 2022

We have 3 weeks sprint cycle.

From what you say, you have no Sprints at all. The whole point of a Sprint is to meet a Sprint Goal by producing at least one Done increment of immediately usable work.

That doesn't sound like it's happening, and the empiricism you'd expect from the Scrum framework is not therefore being established. I'd suggest that, rather than trying to resolve the symptoms you describe, it might be better to focus on that more fundamental issue.

07:39 am March 30, 2022

Thanks, Ian Mitchell.

I understand. Actually, there will be at least one done increment in each sprint cycle as some of the stories will come to end in each sprint cycle. however, it will be like we planned for 10 stories but we only completed 2 in the sprint cycle. 

These 2 stories might have taken 3 sprints to complete.

03:06 pm March 30, 2022

I agree with @Ian.  You are trying to fix the wrong problem.  Your difficulty is that you are not breaking items down into something that can be done in a single Sprint.  This comes from the Sprint Guide section that describes the Product Backlog. 

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. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

You state 

  • The story represents a request for a single training course that can be broken into lessons or learning objectives but it doesn't make sense to create a story for each lesson/learning objective. Also, the course request can be broken into lessons post-planning phase only and that is the part of the development phase.

Why doesn't it make sense to create a story for each lesson/learning objective if it will allow you to complete a body of work in each Sprint? The intent of a Sprint is to provide a valuable increment of work.  In software development it is quite common for teams to deliver portions of working code that will be built upon to create a feature. For example, we may deliver a set of code that interacts with a set database tables and displays part of the information the user needs in the first Sprint. The next Sprint does the same with a second set of tables.  It may take us 4 Sprints to completely present all of the data that the user wants but we are able to give them pieces of information every Sprint. 

In your case, the training course may not be able to delivered until all of the parts are ready but you can still create complete work each Sprint.

@Ian mentioned that you are missing out on the empiricism that is so valuable.  If you aren't familiar with empiricism, it is the belief that all knowledge is gained through experience.  In Scrum, and many other agile iterative practices, a big benefit is being able to get user feedback quickly and then adapting to that feedback as you go.  That is the main purpose of the Sprint Review. It is a time that you can share your incremental progress with your stakeholders and gain feedback, which is then incorporated into your Product Backlog. 

Now, let me give you this caveat.  Both @Ian and my responses are based upon the Scrum framework.  I raise that point because your description of what you are doing does not sound like you are using the Scrum framework.  Using terms like Sprint does not mean you are using the Scrum framework.  Also since you never mentioned a Sprint Goal, or any of the other artifacts/events in Scrum it isn't clear that you are fully using the Scrum framework.  User Stories are not mentioned anywhere in the Scrum Guide and your entire question is focused on them. There is nothing wrong with using some of the terms or practices of Scrum in combination with other methods, procedures, and practices.  But as the Scrum Guide says in the End Note

While implementing only parts of Scrum is possible, the result is not Scrum.

04:31 pm March 30, 2022

These 2 stories might have taken 3 sprints to complete.

If that's the case, then your velocity can be stated as being 2 stories per 3 Sprints. Velocity is the rate at which work is Done.

For planning purposes your velocity of stories per Sprint is zero, in so far as within any one Sprint, you cannot expect that any one story will be started and brought to completion.

From what you say, you could arguably plan to retire technical debt at a rate of 2 undone stories per Sprint. The problem is you will continue to accrue technical debt at the same rate, a situation which has evidently become normalized. That's the core issue you need to resolve because it's hobbling empiricism and causing the feedback you'd expect from Scrum to become attenuated.

09:08 am March 31, 2022

Thanks, @Daniel Wilhite and @Ian Mitchell for your responses. These are really helpful.

I will work on your recommendations.

Thanks

Sharad Singh