Add a 'Blocked' status

Thanks for replying Mike.

Yep that is a good suggestion. I will use labels for now.

I still think a special status that made the story highlighted red would be useful, you need that info really in your face, a label can be glossed over pretty easily. You would have to intentionally go searching for blocked stories to really find them, they won't stand out in a long list.

I have already become pretty practiced at ignoring the labels, since they bump the alignment of the heading out, you have to sort of develop a blind spot for them.

We've been using labels and it sucks. Labels do not stand out significantly enough. It might work if a label could be in all CAPs but low, tracker downcases the labels. Or if labels could be config'd to have background color so they stand out.

The original request is very valid. Blocked is a first class status. Some work has been done but something external is standing in the way so pay attention to me. The people I work with (dev and biz) would love for it to stand out more.

I agree with Tinomen. A blocked tag, while searchable definitely isn't the best solution.

And as for highlighting, I think a light red would be awesome

When working on a story, how do I handle a roadblock - like if I need to go back and ask a client a question and am waiting for their response? Essentially I just need a Hold state or something.

This reply was created from a merged topic originally titled
Hold or Roadblock State?.

Not sure how it affects iterations, but in our short experience, we feel we sometimes have to turn "started" log entries (tasks) into "Not started" manually if for some reason or another we have to stop working on it due to maybe rearranging the current sprint backlog or simply having to suddenly work on some other project for a few days.


Perhaps there is a logic to it but "pausing" or making "pending" a log entry seems logical in this cases, so you can "restart" when you get back to it.


I know it's not a case of tracking hours on a task and that is the sprint time what has to be tracked, but if you know you are not working on it for a couple of days it does not seem logical that it shows as "started".

This reply was created from a merged topic originally titled
A "pause" button.

I don't like the term "blocked" It sounds very anti-productive and more like if that status was up, it would mean I'm not supposed to work on it.

Paused or on hold would be good terms too, probably better than blocked indeed.

Eddie, Thijs: the whole point of the blocked status is it's a really big deal. The reality is that in any development you will occasionally get situations that you can't resolved and that prevent you from completing your stories for the iteration. When this occurs it needs to be SHOUTED in the most obvious way possible so that the project lead/scrummaster etc can know that it has occurred and take steps to remove the roadblock. It is all about productivity. This term isn't one i made up but is common parlance in the Scrum methodology.

The problem is that I don't believe this software is purely for development purposes. I use it from a project management standpoint managing 8 employees on my marketing and development team.

As far as Scrum goes, why not change that iterations to sprints?!

But after your argument, I do agree that blocked is a good term for a roadblock of monumental cases, but hold or pause relates more to work flow for me and should not be dismissed by the developers.

Perhaps a better use of BLOCKED maybe what you described as above: The scrummaster or project leader is the only one that can set that status. If that's the case, then I'm posting my advocacy for HOLD or PAUSE in the wrong thread.

It sounds like some people need states that other people wouldn't want (I don't think I would enjoy a "blocked" state, but I can see why some do).

+1 for custom states

It would be great to include the Blocked state for user stories, we are working integrating QA and Dev in the same project and QA needs this status in order to set an urgent task to Dev, some user stories can not be tested if certain things are ready.

We need a pused state... really a cant get why it isnt here now :|

I, as a software developer, would like to be able to mark a story as "impeded" and describe the impediment, so that this is recorded in the system and can be reviewed later by the lead engineer or product manager.


Basically, the idea is to offer a second button after a story is started in addition to the "Finish" button. Upon pressing a button named "Pause" or "Impeded", the software developer would receive a prompt asking them to describe the impediment. These impediments can later be reviewed and resolved by the product manager or lead engineer.


In fact, it would be great to even have all impediments sent to people like upper level management or the CTO/CIO, because at the end of the day, a manager's responsibility is not to make decisions, but instead make it possible for other people to work effectively and make good decisions.

This reply was created from a merged topic originally titled
Ability to pause a story and record impediments.

I just want to add that one of the most important features of this feature would have to be memory. Labels simply don't cut it because it doesn't have memory. Simply marking something as blocked does not say why. Yes, I could add a comment as well, but that helps in the immediate short term for one story, but once that story is delivered, the cause of the impediment is quickly forgotten.

The way I see it, there are two ways of dealing with impediments. There is the short-term solution where you remove the impediment for just that one user story, but short-term solutions don't necessarily remove impediments at the root and they may crop up again repeatedly impacting future stories. TO solve repeat impediments at the root, the system needs memory and the ability to review all the impediments from the last week, last month, last quarter, etc.

Even better would be if this "impeded" button had a timestamp that could later be used to quantify the severity of an impediment in number of hours/days/weeks that a story was blocked.

There is no stronger argument for making a permanent organizational change than evidence. And a page that aggregates all the impediments, gives you a macro view of what people, departments or systems cause the most impediments and with a time measurement of severity, you can quantify loss. This may not be necessary in a small one project company, but for any company using pivotal tracker where there are dependencies with people outside the team, this would be extremely valuable in soliciting top management action.