Loading Profile...
Where does the PRD vs Spec go? When is a story ready for QA?
How does Pivotal support the flow of PRD > Spec > Implementation > QA Testing? Even in a startup with high-velocity iterations, these steps are all quite important.
FYI, we're now using the description field to store links to our PRD's and Specifications. The reason these are important, is that developers a) need a more detailed description on look&feel, usability, and functionality, and b) need to understand how the particular feature fits into the existing architecture, which conventions should be applied, and how it affects certain others parts of the code. A developer can usually not make these decisions, nor would he want to.
The story buttons going from "Start" to "Finish" are ok, but "Deliver" seems odd. We're now saying QA has to happen after that step.
It would be nice to customize both a story (the fields it has) as well as the story actions (buttons).
FYI, we're now using the description field to store links to our PRD's and Specifications. The reason these are important, is that developers a) need a more detailed description on look&feel, usability, and functionality, and b) need to understand how the particular feature fits into the existing architecture, which conventions should be applied, and how it affects certain others parts of the code. A developer can usually not make these decisions, nor would he want to.
The story buttons going from "Start" to "Finish" are ok, but "Deliver" seems odd. We're now saying QA has to happen after that step.
It would be nice to customize both a story (the fields it has) as well as the story actions (buttons).
I’m slightly confused
4
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
-
Inappropriate?Hi,
We like to think of stories as a placeholder for an on-going conversation, and encourage developers to communicate with product owners often, especially just prior to starting a story. In general, we try to break every feature/requirement down into small, concise stories, where each builds on existing functionality, and adds business value to the product incrementally. It's the process of breaking larger features down into small stories that uncovers a lot of the detail. Also, since requirements tend to change, we find it easier to keep up by having the backlog of stories act as the knowledge of current requirements, rather than separate, static requirements documents that need to be kept in sync with a changing reality.
Nevertheless, it is still useful at times to link from stories to external resources such as style guides, interactive mockups, etc. We use the description field and/or comments for this.
The "deliver" action in the story workflow is used to communicate that the implementation of a given story has been deployed to some environment (demo/staging/QA), where the product owner can verify that it meets requirements, and works as expected. The primary focus here is on early customer feedback, but this verification and acceptance step could encompass quality as well, and QA could essentially play the role of an extended customer. The Tracker story workflow does not explicitly support QA verification as a separate step, but for teams that do have that need, it's possible to use labels for additional workflow steps (for example "ready for QA", "QA verified", etc). In the future, we hope to add the ability to add custom story workflow steps.
Hopefully this will help, and sorry it took so long for us to respond to your question.
EMPLOYEE
