Custom story workflow/states/status (was 'more acceptance states to support testing on multiple environments')

Edit Subject

May i suggest an incremental approach to custom workflows where it's possible to turn on these extra steps that we've requested.

And if I can suggest the ui design, you wouldn't even need different buttons ... just a letter by the accept | reject buttons like this:


This would save us a ton of hassle and time and make our customer feel so much better about the "what's going on, and what's actually delivered to users??" question.

Thanks for responding!!

I like this idea... and the UI seems pretty simple. Though I'm not sure the D/S/P would fit everyone's workflow since different teams have different systems (and names for those systems).

To keep it simple, perhaps just an option to add any number of extra accept/reject steps and then a number next to it instead of the letter? That way there's very little customization UI that needs to be built and it gives us what we'd need.

yes! great suggestion!

How do people use 'delivered' vs. 'finished' ? Is there a way to customize the states that a story can go through?

This reply was created from a merged topic originally titled
delivered vs. finished.

The current set of states (start -> finish -> deliver -> accept/reject) hits the 80% case. Unfortunately too many of my projects are in the 20% and this is an increasing source of friction. I'd love some sort of additional state definition here so I could do things like start -> finish -> deliver to staging -> accept/reject -> deploy to production

This reply was created from a merged topic originally titled
Custom Workflows would rock.

pitosalas: we use 'finished' to signify when a story is done and committed to the master code repo. then it is QAed on our staging environment, and while there is in the 'delivered' state. depending on QA success it then goes to either accepted or rejected.

We could use some custom states as well. In particular, we could really use one between Finished and Delivered for "Code Review".

I've had to take my team at a large insurer from Pivotal back to Jira+Greenhopper because of this shortcoming. Not that Jira is horrible - but compared with tracker it seems like a step backwards.

In addition to extra acceptance steps, support for BAs by having an extra step at the start for Elaboration would be useful. There are also occasions where deployment to system testing stages occurs before deployment to production. The ability if users to extend a (linear) workflow as they please would be very advantageous.

I was considering the idea of having more states, and I had an idea that I want to play with. I was thinking of using "Release" items in Pivotal to represent simple markers. Have a release that says "Code Reviewed" for instance, and leave it always in the current iteration. All of the tasks that have been at least started would be in that iteration, but place them after the Code Reviewed item while waiting and before them, perhaps after another item in the flow or whatever. I suppose you could place these additional items either before the "Start" of a task for earlier process items that are still happening during the backlog or icebox, and then some during the development, after the "Start" of a task during the current iteration.

Not perfect, I know, but perhaps a way to work around the current limitation of Pivotal, which is so elegantly simple in every other way (oddly enough, that is its charm and its weakness).

Nice idea, Rick. I'd have tried that if I'd thought of it.

Instead I tried to workaround by using 2 projects - one at a story level, the other at a task level, using the story level workflow to indicate BA/Tester semantics and the task level workflow for devs. A bit of scripting would keep all in sync. But I had jira-familiar staff with whom this jury-rigging did not sit well. So I gave in, and now I have IMs doing the usual greenhopper juggle.

Not that there's anything wrong with that ...

The original post for this idea is great and is what we desperately need. It is too hard to use labels to keep the various phases separated. The steps we need are:

- not yet started
- started
- finished
- delivered
- accepted (on demo)
- rejected (on demo)
- delivered
- accepted (on staging)
- rejected (on staging)
- delivered
- accepted (on production)
- rejected (on production)

I added the "delivered" phase inbetween each since once it is accepted (on demo), it would then be ready to be delivered to staging.

Just hit this problem also on our team. We really need to be able to have exstra steps for acceptance of how it works on staging, and then acceptance of the code so It can be deployed

Yep, I agree, we need more states. I need to have an audit trail of peer reviews. Is this still being considered at Pivotal? When might we see it?

Please keep the states for a story flexible. Different teams will always have different processes depending on their business and development technology choices.

My team would probably drop the "finished" state and add a "not planned" state for stories that we aren't planning to ever implement.

Every team may have a different set of steps/stats they need. So, I don't see the point in saying "my team needs A and C". +1 to add custom steps feature :)

We definitely need this - would really help the tool gain traction in certain departments

Is it possible to have more testing statuses? eg, has been delivered on staging and accepted, now has been delivered on live, and accepted. Currently there's only enough statuses for delivery to staging for us.

This reply was created from a merged topic originally titled
Why can't you deliver/accept on staging, then deliver/accept on live.

I'd like to be able to close stories which were not actually completed or accomplished. You might call this state something like "Dismissed", "Closed", "Won't Do", or such. Once in a while, a story will no longer need to be done, or the requester doesn't want the feature any more, or a bug will be discovered to be a non-issue, or the item is a duplicate, etc. Using "Accept" and "Done" is inappropriate for these things, because no work was actually done (or the work was not finished). At the same time, neither is it fitting to outright delete the item, because oftentimes, useful commentary has been added to the item which will be useful for debugging and troubleshooting in the future.

This reply was created from a merged topic originally titled
New state: "Dismissed" or "Won't Do".

Is there a possibility to configure story's list of states? For example, we need 'verified on stage' state before 'delivered'.

Any help appreciated, thank you in advance.

This reply was created from a merged topic originally titled
Is it possible to have 'verified on stage' before 'delivered' state?.

Sometimes you start a Story, but can't yet finish it because of another obligation or problem. Instead of keeping that project in your current, you can select hold and it'll go down to the end of the list of the backlog. -- something like that would be nice instead of changing the status back to "Not Yet Started," because I most certainly have started it.

This reply was created from a merged topic originally titled
Story Status: HOLD.

It is a common agile concept that a story is 'Blocked' if progress on it cannot be made due to some sort of unanticipated external issue that can't be addressed by the story owner.

When a story is blocked, whatever is causing the issue needs to be addressed as quickly as possible in order to get things moving again and finish the agreed features for the iteration.

So it would be nice if there was an ability to mark a story blocked in pivotal, and highlight it in some way for project lead/scrum master etc to address ASAP.

This reply was created from a merged topic originally titled
Add a 'Blocked' status.

There should be a status like "Canceled", where a story could be canceled, or will not be done. But it will stay in the project and not be deleted, since there could be comments in the story indicating why it was canceled.

This reply was created from a merged topic originally titled
New status "Canceled".

occasionally we'll run into a blocker on a card which requires someone's attention who isn't immediately available. It would be nice in those cases to be able to flip the card to a "blocked" status which changes the row color to red, so that everyone on the team can see that the card is blocked. Currently this happens in comments, which aren't immediately apparent. We can make a label, but it's rather subtle when displayed alongside all the other cards.

This reply was created from a merged topic originally titled
add "blocked" status which changes row color to red.

There definitely needs to be an additional "deploy" state. Right now we simply don't know when a story that's been accepted on our staging server, makes it in to production. This seems like a simple and obvious workflow - it would be awesome if Pivotal could add this. It's the one and only feature that's really lacking in Pivotal Tracker, otherwise we love the product.

Right now we test on a staging server when a story is in the accept/reject state. However once we accept a story, its immediately set to Delivered. But we don't know when that story has been put into production so it's running on the live server. There should be an additional state so that the developer can set the story to deployed.

This reply was created from a merged topic originally titled
After accepting a story it should be a Deploy state before Delivered..

rather than attempt to edit or reformat this, I'm just pasting an email that I sent to Pivotal

Here's our pain-point:

Sometimes a "bug" story is opened which can be addressed by a direct fix to the production data. (Often this is due to something a user did inadvertently ;-)
Most times a "bug" story requires some code change which will be deployed to a staging environment.

In the first case, the developer's "Deliver" means that the fix can be observed and tested/verified on the production environment. When the story is "Accept"ed, it is really done—nothing more for the developer to do.
In the second case, the "Deliver" means the fix can be verified on the staging environment and the "Accept" means that the story can be deployed to production.

So, my suggestion/request:

Enable an optional workflow state(s) between "Accept" and "Done" which is(are) chosen by the deliverer. I imagine that just like the "Reject" action prompts for a comment (or the "new label..." asks for the value), the "Deliver" action could prompt for where the story has been delivered.

Present workflow:

Unestimated
(Estimate)
Not yet Started
(Start)
[1] Started
(Finish)
Finished
(Deliver) [a]
Delivered [2]

[2] (Accept)
Accepted

[2] (Reject)
Rejected
(Restart) [1]

Proposed workflow:
When choosing to Deliver at [a] prompt for an environment (perhaps configured from an ordered list) such as "staging" or "production". This indicates where the acceptance criteria should be evaluated. Then when the story is Accepted it could be shown that the story was "Accepted in staging" or "Accepted in production" (perhaps with a tool-tip). An environment might be marked "final" such that a story that is "Accepted in production" is ready for Done at end of iteration (which is just Accepted today). The button for transition could be "Deploy" when in the "Accepted in staging" state.

for a "data" bug fixed directly in the production environment:

Finished
(Deliver) => "production"
Delivered to production
(Accept)
Accepted

-OR- for a bug that requires evaluation in a non-production environment:

Finished
(Deliver) => "staging"
Delivered to staging
(Accept)
Accepted in staging
(Deploy)
Accepted

While I don't presently have a CI server, I could imagine having the CI server do the deploy to the staging environment upon testing green and informing Pivotal of the "Deliver => 'staging'" transition.

-Rob

I like the UI suggestion from pixelperfect to have a simple letter next to the action button, but an automatic label might work just as well (for me).

Can I change the project's workflow?
Let's say, after setting a story to "Finished", it could be able to be "tested" by another member of the team... So, instead of "Deliver", a new button would be present: "Test"...

This reply was created from a merged topic originally titled
Customize Project's workflow.

I have a "spec" label that I'm applying to all stories that haven't yet been fully throught through or speced out.

Usually until the spec is done the story can't have a point value assigned to it and [development] work on the story can't be started...

What would be ideal is if there was a "Specifying" status for stories that would come before the "Started" status. This is when a Business Analyst or the Programmer would brainstorm with the stakeholder about requirements, prepare wireframes and requirements docs etc.

What would then be even better is if the story could have different owners at different stages of it's completion... so a BA might be responsible for nutting out specs (the Spec Owner), a developer responsible for implementing some code (Implementation Owner), and a QA person responsible for testing once the story was deployed (Test Owner). However I think I digress here from the original idea/suggestion... I'm just thinking a bit about how it could fit into a full development lifecycle workflow a bit better in PT.

This reply was created from a merged topic originally titled
Add a Specifying status for stories.

It would be great if we can have two levels of acceptance for a story. One by the quality assurance team and the second by the requester of the story. This will increase the quality of the features that are developed. Right now we are doing this outside pivotal tracker in a spreadsheet.

This reply was created from a merged topic originally titled
Have an additional state for stories.

Please add the ability to customize story states. We would like to add wireframe and design states before development starts and a testing state with accept / reject prior to a product manager accept / reject state.

If you add those states for us we wouldn't need to customize the states, but I am guessing not everyone would want these states. Ideally these could be customized per project and also at the account level (inherited by projects where this customization has not been set up).

This reply was created from a merged topic originally titled
custom story states.

This has been a really popular request for a year or so. Any updates on when it might get some attention?

Best thing is to follow suite with AgileZen and Kanbanery, and make the panels rename-able, and add the ability to add/remove panels in the workflow. It's pretty straightforward and it's really a missing feature on Pivotal Tracker... !!

+1 @joshrace - That's all I want: rename the panels, add/remove panels, and maybe reorder panels.

I don't think we'll move to Tracker until this dream is a reality.

I want a "Deny" button. Currently there are only two ways a story can end up, as "Accepted" or "Deleted". Neither feels right for a feature that someone wanted but that wasn't a good idea, or a "Bug" that wasn't a real bug. "Delete" looses the history of the story, which is bad because that history can contain useful information. "Accept" indicates that the feature/bug has been implemented, which isn't true. (You could combine Accept with a label or a comment that said "Denied", but it would be better if "Denied" was its own state.)

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

We would appreciate if one could customize the workflow. We do Unstarted, Started, Finished, Accepted and Delivered. Our testers test the finished storys before the team merges (delivers) it to the trunk. The same number of states but with accept/reject and deliver interactions swapped. Until you add this feature, could you please share how Pivotal Labs uses the current workflow?

This reply was created from a merged topic originally titled
Customize workflow.

We've love to have another queue added to our account that we place all of our ideas into that comes before the Icebox. For us, the Icebox means the idea has been qualified (I.e. It's an interesting idea that we should implement at some point in time). But we have lots of other ideas from our team or from users that we'd like to place in a queue beforehand that are unqualified (our product team then filters through those and puts them into the Icebox when we deem it's worthy). Does this exist or is it easy to add? Are we missing something?

This reply was created from a merged topic originally titled
Queue before Icebox?.

Any news on this? I just started a new project and was thinking how incredibly useful it would be to be able to demarcate btw coding and QA stages.

Likewise, I'd like to be able to customise the status headings.

It will be really nice to customize status. Currently, only labels can be customized.

If we can have an option to customize status of a story on project level, then it will be much easier to use within custom workflow.

When a story is in the "blocked" state, it should have a different background color to make it stand out (like light red).

When you change a story to "blocked" it should go out of current, just as it does if you mark it "not started".

This reply was created from a merged topic originally titled
Tracker needs a new status called "blocked".

I have just started looking at pivotaltracker and am thinking of moving from mingle to it. However what stands out really 'loudly' is that the community have been calling for customised states for over a year and yet nothing appears to have been done about it. Am I missing something or have people just been talking about wanting it but not getting anything done yet. Considering all of this relates to agile development, how hard can it be to sort out after a year?

Potential customer....watching

Hey Gary - Right now our most requested feature is grouping stories together, and we've been hard at work on this very feature.

We are aware of how important this is to folks though, and once development and planning begin I will absolutely let folks know.

When someone has requested a story from you, you shouldn't by default be able to accept / reject the story after delivering. Instead "Pending", "Waiting for approval" or similar should be shown until the person requesting the story has accepted or rejected.

This reply was created from a merged topic originally titled
Not accept / reject stories owned by you but requested by someone else..

To inform whatever development is be done on this: our workflow calls for the follow two states (currently we have to do confusing work-arounds):

* a 2nd 'accepted' state -- because we want both the story requester or product owner to OK something first (functionally), and then have QA approve it as well in more detail.
* "canceled" -- because it's weird to just delete a story with all it's information and history when another story obviates it

BTW, dehfne's idea above would be great for the first case -- since it covers both this request and the 'environment-specific acceptance' some others have asked for.

Sounds good.

Allow people to name the "states" to whatever they want, and pick a color. (color of the button).

Have start and finish as default. And have every step have a "reject" option which pushes the state back one with a comment.

start (default)
confirm requirements -- orange
send requirements to bob -- blue
have lunch -- green
push code to staging server -- yellow
push code to QA server -- yellow
push code to production -- red
finish (default)

Then people create their own workflow to whatever suits. And it should satisfy most situations.

I would love this as well, since we need to keep track of which features passed QA but hasn't been deployed to Production and such. It would also be great to have deployed to Prod as a status that get's tracked in the history so we can easily look at which features went live on what day. Any update on when this may be coming?

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!

it would be cool to have an extra state before testing phase. I'll come across a story that's on the "Deliver" state meaning its ready for testing, but the developer would inform me that it's not ready due to different circumstances but he sets it to "Deliver" so that he knows he has built the feature. But then I've got a backlog with stories in the testing state but I cant test them, which doesn't look good. Maybe add an extra state saying "deploy" so that developer and everyone else know's the feature is done..its just not ready for deployment...once deployed it goes to "deliver" where it is ready for testing.

This reply was created from a merged topic originally titled
add an extra state to stories.