Comment by twic

Comment by twic 7 hours ago

1 reply

View on Hacker News

60% yes, but 40% no, because there was nothing after "accepted" - so no way to track "in production" and "validated with users", which are the most important states. You could abuse the earlier states to do that, but then you have trouble tracking internal acceptance. Ultimately, reality just has more significant states than Tracker recognised.

quesera 7 hours ago

A model that has worked well for my teams is to track story/development state and deployment state separately.

They are fundamentally different things, and you cannot always infer one from the other.

  - "Accepted" is the final state. Deployed to prod and verified. Story is finished and can be hidden from active view.

  - "Delivered" is set by QA when they believe the changes are complete and correct, ready for deployment.

  - "Finished" is set by the developer when they finish, push, and create the PR.
Then we use labels for deployment state. E.g. @staging, @sandbox, @production, etc.

It happens sometimes that a Finished story is deployed to staging in integration build X, but then omitted from integration build X+1, for reasons unrelated to the quality of the changes. In this case the story stays Finished (or Delivered) and we set the @staging label when deploying X to staging, but clear it when deploying X+1.

This works really well, especially after writing some glue code to integrate Pivotal and GitHub and your build/deploy flows.

Reply View 0 replies