we are feeling frustrated by a lack of communication because tracker lacks a few states that are integral to our workflow. We need to be able to communicate when something has been accepted on our demo server, on staging and finally on production.
- not yet started
- accepted (on demo)
- rejected (on demo)
- accepted (on staging)
- rejected (on staging)
- accepted (on production)
- rejected (on production)
Tracker is designed to be lightweight, fast and easy to use. We understand the need for customization, and our designers are currently considering how Tracker can support some of these use cases without complicating the workflow. We're looking at using tasks and task multiple ownership to provide a workflow that accommodates different workflows. We've already provided the ability to have multiple story owners, which helps support different activities such as design, front-end and back-end work, and testing.
Our newly redesigned Tracker UI which is currently in beta allows you to put panels in any order you desire. You can also load multiple projects at once for ease of searching, linking stories in different projects, and moving stories from one project to another. It's just the first step towards a bit more flexibility in Tracker, to accommodate the needs of larger teams with multiple projects and different agile approaches. We are currently considering designs for a tailored workflow, but we don't have a timeframe for that right now.
We face the same challenges for making activities such as testing and design visible on our own team. We find that using labels for this works well for us. I blogged about this, we hope you'll consider experimenting with these ideas: http://pivotallabs.com/making-testing...
If you'd like to develop your own solution, you might like to look at our API: https://www.pivotaltracker.com/help/a...
Along the lines of custom workflows and status options:
Putting a started story on hold.
Long running stories or shifts in priorities may cause a story to not be able to be worked on or completed in the current or any near term iteration.
I would like ot be able to put it on hold (a state similar to not yet started but showing that work has been done on it), it has already been started but will not be worked on in the current iteration.
I agree with being able to name the states whatever you'd like. Some folks prefer the button language to articulate a state ("unstarted" "development" "verification" "testing" "acceptance") rather than an action.
All of the ideas here have been great - I hope some of them get rolled in!
I'm sure figuring out how to configure this would be a challenge. We are grateful for all your hard work, Pivotal team!
zomg I love that image... I wanna click that purple button so BAD
This is pretty silly.
I can't even have two rounds of QA "internally approved" and "client approved".
Jumping through hoops and explaining to clients they have to add an "OK to push to prod" label is just not professional and has burned us many times already.
Not having this is literally the worst part of the Pivotal Tracker experience for us.
@Lisa Crispin, it's nice that labels are sufficient for your team, who I'm sure have a lot of experience with the software and feel comfortable using technology like this as part of a daily workflow. I'm telling you from a lot of personal experience that your average client finds this approach frustrating, confusing and prone to mistakes. When planning your roadmap please consider carefully who you think your customer base is, your hand-selected internal team, or agencies that have to regularly work with 3rd parties.
Yes our organization absolutely needs the ability for custom "States" for example if we could just add the "Blocked" state that would be great - we are using labels as a workaround but its not really visible enough - it even be greater developer that when setting a Story to "Blocked" the Requester would get an email.
A related issue is to track when a story is in state "Started" but blocked by a pull request. I developed a little app (free to use!) which :
- Add a label pull-request to the story when a pull request is created
- Add a note to the story when the Pull Request is updated (someone pushes on the branch)
- Mark the story as "Finished" when the Pull Request is merged, removing the label.
The code : https://github.com/ssaunier/mergehook
The app you can use right away ! https://mergehook.herokuapp.com/