0

In 1 sprint, we are having 2 user stories. One is for design and one is for coding/development based on the design. We are having different statuses in Jira like To-Do, Blocked, In Progress, etc. Now, the developer is putting his development user story under "Blocked" as he is waiting for the designs. He is of the opinion that the story is blocked for him as there is nothing he can do until he gets the designs. The dependent story (for the UX designer) could either be in To-Do or In Progress. Is this the right approach ? Should the developer put his story under To-Do or Blocked ?

6 Answers 6

3

I'd ask the team what benefits does they find from having two user stories for the same piece of functionality?

I advise teams not to split backlog items into stories for specific disciplines. In this case, I'd have one product backlog item (one user story) and let the team know that the backlog item is what they're agreeing to if they bring it into the sprint backlog.

In your situation (as I don't like changing approaches mid-sprint), can a developer be blocked on something they haven't started?

Could the developer get early visibility of the designs to understand things like content or data structure?

Are there aspects the developer can work on that they can finalize with the designs?

Questions like these encourage closer collaboration, and remind the team that it's the team that delivers, not individuals.

2

"Blocked" should never be a state in a workflow, which includes a status in a Jira workflow or a column on a board. Calling something "blocked" is a description of the work, but not a status. If something is blocked and To Do, that shows that it can't be started due to some condition. Similarly, if a unit of work is identified as blocked and its In Progress, that indicates that no more progress can be made on the work until something is resolved.

If you're using Jira, using a label or a flag on the issue is a better way of indicating that something is blocked. You can then highlight these issues on your board to make them visible and the team can work to resolve whatever issues are preventing progress.

The problems that you are facing are much more fundamental than being able to identify blocked work, though. It seems like you are trying to start development before the necessary preconditions have been satisfied. There are a few ways to handle this. One would be to have a more complex workflow and use a single issue to track it through the ideation, design, and refinement process before development. Another solution could be to make sure that the necessary design and refinement is done before development so the work doesn't get blocked. There may be other options, too, but I'd say that there are deeper issues if you're regularly having development work blocked because prerequisites aren't met.

1

"Blocked" is normally reserved as a state when the team as a whole cannot progress the item. So in this case, I would not consider it "blocked", because the team can do meaningful work to finish this story.

In the specific case of this ticket waiting for the design decision in another ticket, you have two choices: you can either (a) not put the ticket into the sprint until design decisions are made and done the previous sprint, or (b) make design decisions a task under the story, just like implementing, code review and testing are (or should be). But having a story in the sprint that cannot be worked on until another story is done is not really good. User stories should be independent. And bring value to the user. In this case, they are neither independent, nor does finishing just one bring any value. The user won't notice if you already have the design done. The button is still not there, even if you made a sketch of how it would look if it were.

Either way, saying it is "blocked" is a little strange, because if you view it that way, it has been blocked since the sprint started.

In the end, there is no law governing tags in your workflow system. You can name it and tag it with whatever you want. But for the teams I have been part of, "blocked" always meant that we as a team cannot progress this item and we need outside help or input.

Bring it up in the retrospective. See what your team thinks and how they want to handle it. Having dependencies between stories is never good, but I don't know your team structure or workflow enough to make any real suggestions here.

1

He is of the opinion that the story is blocked for him as there is nothing he can do until he gets the designs.

The reality is that without any design and refinement, the entire sprint is blocked, so your designer is correct in a lot of ways! What you need to ensure is that you ensure any refinement and design is completed before development commences and that might include design decisions as a ticket.

You need to emphasise to this designer that you are all part of a team and that blocked is to be used realty when the team cannot move forward.

2 user stories. One is for design and one is for coding/development based on the design

I'd be interested to hear more about this

1

A blocked task must contain a reason why it is blocked and someone else from the team, or external to it, must be assigned to unblock the task. The person assigned by someone else might not have the answer, so further assigning people until finding the answer.

Outside the process, a meeting can unblock a task also.

If the task is blocked due to dependency conflicts, I would highlight this as a bad prioritization by the product owner as this should be discussed with devs and taken into account by him/her during the sprint planning.

I bet the above-mentioned issue is the root cause of the problem!

Imagine the PO wants a new frontend that will require designs, but they start a sprint with no designs... the entire team will look at each other while designs are getting done... crazy!

New contributor
Pablo Leone is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
0

This is interesting.

My opinion is user stories are meant to be independent and assuming two user stories for a sprint does not seem right with me.

Create one user storie for it and in your worklow you can have blocked there so as to be an indication to the team that the design has to be done in time.

Blocked in the workflow is a good thing but it shouldn't be mixed with product backlogs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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