TASKS VS USER STORIES PROGRESS – The story of WIP –  Which should I finish first?

Who should we finish first, all of our assigned tasks or the user stories as ordered in the sprint backlog? Anh is all of that related to limiting WIP?

 What’s a User Story? – To put it simple In agile software development, the user story is a short, plain-language description of a functionality written from the user’s perspective. Many agile experts often define the user story as the smallest unit of product development work that can lead to a full user functionality feature.

What is a task (in the simplest manner)?  – It’s time to get to work. User stories capture what you need to create, but now is the time to knuckle down and put together the work that needs to be done so that you can bring those user stories to life. You split your user stories into tasks, estimate (if common) and it will help you track your user story progress from start to finish.

What is WIP? – In the case of agile development, work in progress (WIP) limits set the maximum amount of work that can occur in each workflow status. Limiting the amount of work in progress makes it easier to find inefficiency in a team’s workflow. Bottlenecks in the distribution pipeline of the team are readily evident therefore easy to attend, fix and recheck the efficiency of the flow. The entire flow becomes fast and efficient and its easy to optimize workflows for value delivery.

*Read more about limit WIP

**a Kanban board with WIP limits

User stories, tasks and WIP –

Your user stories have helped explain just what your program needs to do from the customer’s point of view. But now that it’s time to start coding, you’re going to have to look at these stories differently. Each story is a set of individual tasks, small bits of functionality that can be combined to make up a single user story. The task describes a development work that a developer needs to use to build part of a user story. The tasks bring another level of complexity to the actual coding you’re going to do with a user story.

But who comes first to done a task or a user story?

Tasks unpacked from various storylines and assigned to the one developer? Are all should be finishing all first and are more important than being able to finish tasks that are only related to certain user story?  Even if it means stopping and not continuing on my specific mission?

Or finishing story by story, regardless what tasks a specific skilled developer has next. The priority is to finish the user story

The answer is, of course user stories priority is first.

The sprint backlog is ordered in a what that user stories placed higher in the list should be finished first (please note, the backlog is not an ordered list of tasks, rather an ordered list of user stories) . Furthermore, we prefer finishing a story then starting stories.

I any case, limiting Tasks and stories WIP will help us achieve flow efficiency of both and mainly on value delivered (user story). Use WIP to limit the amount of work in progress in the tasks level and in the user story level to speed your value delivery and get the work done.

Stories vs. tasks – Suggested below are three ways to set your focus:

1) Stories at the top of the sprint backlog, should be finished first. Meaning, tasks related to those stories should start first and finish first.

Completing a task, meant that you have finished one item out of the bundle of tasks composing a user story. Staring a new task that fits your skill and at the same time starting a new user story will result with a risk that your story may not be finished. You and your team must make sure to focus on user stories WIP as well as on Tasks WIP. The team needs to decide what is the maximum WIP allowed for tasks and stories and to keep the order scrum backlog as the work order headlight.

2) Be a picky guy! Focus on user story WIP as well as on tasks WIP – as a scrum team member do not start working on so many items at once

Since we only have a limited amount of time to finish our work (I mean our value delivered = user stories), we need to be careful about what we start. It has no true value to finish only my tasks without considering the delivery of the user stories first.

If there are fewer tasks on our list, we will concentrate on what is important to us to finish first, instead of concentrating on several things at once. Focusing on so many things can be daunting and can stop us from completing what we’re starting to do. Starting a task, represents starting a user story. Your time and resources are minimal. You can’t do it all, and if you fill your time with a list of to- do’s, you might not do a good job, or you might not complete the most important thing first or at all.

3) Let the passion of the wheel drive

If you’re excited about a project, you’re far more likely to finish what you’re beginning to do. When you’re motivated, and the project is essential to you, there’s a far greater chance that you’ll finish it! You’re more likely to pick it up, and you’re able to work long and hard to finish what you’ve begun. When you’re passionate about something that you want to complete, so the end is just as important to you as the beginning. So before you start a new project, ask yourself these three questions: why is that important to my team and me? I know I love the idea, but do I need to be the one to do it, or do I help someone else’s dream? Do I care enough about this project to make sure I see it through until it’s done, no matter how long it takes?

As a scrum team, Everyone should be connected and accountable to the user story completion. So it will be easy to shift the mindset to user story completion over completing “my personal tasks” in the sprint.

4) Consider the rate and decide if you can pay for it!

We all have lots of stuff that we want to do (WIP), but all of them come at a cost. There is a cost at the beginning, and there is also a cost at the end.

Before you say take a new tasks on your schedule and yourself what will be the cost? Helping another team member promoting his. Hers tasks before moving to your own assigned next task? Comparing to the delivery value, this is a fair price to pay.

By paying this price, You gain the value of knowledge sharing, learning, exposure to new activities of other team members and building your ability as part of a scrum team to answer diversity of needs from the scrum team. Will you make it to your personal finish line? Will you finish all your tasks? I don’t know, but your team will probably finish more delivery goals which are far more important then personal tasks coding which has left out of the delivery set.

How to maximize your WIP?

Like any new operation, WIP limits can come at first feel uncomfortable. The goal here is to maximize the team efficiency and speed over the long term, and short-term malaise is a good thing. Avoid the temptation to raise the WIP cap only because the team is still hitting it.

Now, that we learned to limit our WIP and focus on what important to deliver take advantage of this opportunity to improve ability – preferably by training the team and giving each member new skills or making some part of the development process more effective.

Below are some ideas how to maximize our delivery using WIP limit:

• Regularly scale individual tasks. It is crucial to hold unique functions to a maximum of hours of work while breaking down requirements and user stories. Too big of a tasks will hold your progress even if you limit your WIP the right way. Doing so improves the team’s ability to size confidently, which helps avoid bottlenecks. Nothing slows down the team and aggravates WIP’s boundaries like a large work item that blocks the pipeline either it’s a task or a user story.
• The WIP map limits the abilities of the scrum team. Establish an exact status for the work of the specialist. If there are bottlenecks, in this case, take the opportunity to help other team members to add some of the additional ability of the specialist skills set and improve the flow through the whole team.
• Minimize idleness. If a team member has some downtime, urge them to support a team member upstream or downstream. They’re going to add to the overall productivity of the team and learn something along the way!
• Preserve a tradition of sustainable engineering. Work within progress limits does not mean that developers need to hurry through work to prevent overloading work in a specific situation. They are intended to encourage sound, agile innovation practices that protect the quality of the product and the code base’s health.

Related references:

http://www.agilebuddha.com/agile/agile-thinking-stop-starting-start-finishing/

https://www.globallogic.com/insights/blogs/agile-thinking-stop-starting-start-finishing/

https://sites.google.com/site/wicmitchell/home/limiting-wip-stories-vs-tasks

Back to Blog