Try Usersnap for Bug Tracking<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\nWhy Pivotal Tracker?<\/h2>\n\n\n\n
So first things first.<\/p>\n\n\n\n
You might ask: Why Pivotal Tracker? And what makes Pivotal Tracker a better project management tool compared to other tools out there, like Trello<\/a> or Asana<\/a>?<\/p>\n\n\n\nHere\u2019s my personal answer.<\/p>\n\n\n\n
Pivotal Tracker<\/a> is a collaborative & lightweight project management tool developed by Pivotal Labs, a company whose expertise in agile development is widely known.<\/p>\n\n\n\nThe main difference Pivotal Tracker has to other project management tools are their so-called \u201cstories\u201d. Pivotal Tracker focuses entirely on these stories.<\/p>\n\n\n\n
A story is basically a description of a new feature, bug or simple change request, considered from the perspective of the user. This not only helps you to prioritize your stories, but also lets you focus on what\u2019s important for the user.<\/p>\n\n\n\n
Simple workflows are always the best<\/h2>\n\n\n\n
Pivotal Tracker projects consist of 4 different lists: icebox, backlog, current, and done.<\/strong><\/p>\n\n\n\nOn the one hand, this workflow is pretty basic, and on the other hand, it\u2019s lean and helps you to focus on your real work.<\/p>\n\n\n\n
Stories: Features, Bugs, Chore, Release<\/h2>\n\n\n\n
As mentioned, stories are the core heart of Pivotal Tracker. Pivotal divides stories into the following sub-categories:<\/p>\n\n\n\n
\n- Feature<\/li>\n\n\n\n
- Bug<\/li>\n\n\n\n
- Chore (A chore is a story with no direct business value, but simply needs to be done, e.g. a \u201ctech task\u201d)<\/li>\n\n\n\n
- Release<\/li>\n<\/ul>\n\n\n\n
Make use of the icebox<\/h2>\n\n\n\n
The icebox seems kind of new if you\u2019re coming from other project management tools and using Pivotal Tracker for the first time. However, the principle of the icebox is simple and it\u2019s the place to start a new project.<\/p>\n\n\n\n
The icebox is the place where you enter all your features and ideas at the project start as well as throughout the project itself.<\/p>\n\n\n\n
This means that any new story goes to the icebox first. The product owner can then decide and prioritize.<\/p>\n\n\n\n
Clean up your backlog<\/h2>\n\n\n\n
The backlog should be your real workspace. Stories which you and your team would like to tackle first are moved from the icebox to the backlog. The higher the story is in the backlog list, the sooner you\u2019ll start working on it.<\/p>\n\n\n\n
Pretty simple, huh?<\/p>\n\n\n\n
The Pivotal Tracker workflow<\/h2>\n\n\n\n
Story statuses might sound a bit confusing at first, since they differ a bit from other project management tools. But you\u2019ll soon benefit from the advantages that come with the following statuses.<\/p>\n\n\n\n
When a story entered by your project team into the icebox gets \u201capproved\u201d and it is concluded that someone will be working on it, it will be moved to the backlog.<\/p>\n\n\n\n
As soon as a story is listed in the backlog, it gets the status: Start. If, for example, a developer starts working on that story, he or she will press the start button and the story will automatically be moved to the Current list and get the status: Finish.<\/p>\n\n\n\n
When the developer finishes his task the status will change to Deliver. Once a story has been delivered, it can move up to the story acceptance (Accept vs Reject).<\/p>\n\n\n
\n![\"pivotal](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/pivotal-tracker-workflow.jpg\")
<\/figure>\n<\/div>\n\n\nOnce a story is rejected, the status will move back to \u201cre-start\u201d, allowing your developers or designer to re-work the story tasks. If the story gets accepted by the product owner, it will be moved automatically to the \u201cdone\u201d list.<\/p>\n\n\n
\n![\"pivotal](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/pivotal-tracker-workflow-2.jpg\")
<\/figure>\n<\/div>\n\n\nMake use of the search & save search queries<\/h2>\n\n\n\n
Pivotal Tracker offers you a comprehensive search interface which allows you to search and filter for different stories. This comes in quite handy when working on a large project with a lot of people involved and a lot of created stories.<\/p>\n\n\n\n
Searches are performed across all story text (e.g. title, description, comments, tasks, requestor, owner, and a lot more).<\/p>\n\n\n\n
I\u2019d recommend to check out the following search queries:<\/p>\n\n\n\n
\n- Searching for story state: state:unstarted<\/strong><\/em><\/li>\n\n\n\n
- Search for requesters using full name, initial or user names: requester:THP<\/strong><\/em><\/li>\n\n\n\n
- Search for stories which were created on a specific date: created_since:22\/10\/2015<\/strong><\/em><\/li>\n<\/ul>\n\n\n\n
![\"pivotal](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/search-queries-pivotal-tracker.jpg\")
<\/figure>\n<\/div>\n\nTry Usersnap for Bug Tracking<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n<\/p>\n\n\n\n
Further ideas for your search can be found in this help section of Pivotal Tracker<\/a>.<\/p>\n\n\n\nWorking on public projects?<\/h2>\n\n\n\n
By default, all projects are private. This means that those projects are only accessible to you and to the users which you explicitly invite.<\/p>\n\n\n\n
On the other hand, public projects are visible to anyone, in read-only mode. Importantly, public projects also appear on the public directory<\/a> of Pivotal Tracker. So if you\u2019re working on an open-source project or something NPO- or NGO-related, public Pivotal Tracker projects can be the way to go. (Transparency FTW \ud83d\ude09 )<\/p>\n\n\n\n![\"create](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/make-pivotal-tracker-project-public.jpg\")
<\/figure>\n<\/div>\n\n\nBe aware of notifications<\/h2>\n\n\n\n
So when starting out with Pivotal Tracker and creating and working on your first stories, you\u2019ll soon notice in-app notifications<\/a> as well as email notifications coming in.<\/p>\n\n\n\nDecide wisely whether you want to be notified via email on every created story or whether getting notified only of relevant state changes is already sufficient for you. If you do not want your inbox be messed up with notifications, I\u2019d recommend making use of in-app notifications instead of getting all notifications.<\/p>\n\n\n\n
Both settings can be found in Profile > Notification Settings<\/strong>.<\/p>\n\n\n\nWrite stories together<\/h2>\n\n\n\n
As mentioned before, stories should always be user-centric and therefore start with \u201cUser can\u2026\u201d. However, a story is not only a feature request from the user perspective, but also a deliverable which needs to be done.<\/p>\n\n\n\n
it is therefore recommended that customers (or project managers) AND developers write those stories together.<\/p>\n\n\n\n
Don\u2019t overuse max-points<\/h2>\n\n\n\n
Pivotal Tracker allows you to estimate the amount of effort needed to finish each story.<\/p>\n\n\n
\n![\"pivotal](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/sample-pivotal-project-template-point-scale.jpg\")
<\/figure>\n<\/div>\n\n\nThe default point scales are 0, 1, 2, 3. Pivotal Tracker allows you to create your own custom point scales for your projects. Simply go to your project settings > iterations and velocity<\/em><\/strong><\/p>\n\n\n\n![\"adjust](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/adjust-point-scale-pivotal-tracker.jpg\")
<\/figure>\n<\/div>\n\n\nNo matter if you\u2019re using the default point scale or customer ones, do not overuse the maximum point number. Reserve those max. ratings for real high priority issues or as Joseph Moore from Pivotal Labs puts it<\/a>:<\/p>\n\n\n\n\nReserve them for \u201cOMG\u201d stories.<\/h3>\n<\/blockquote>\n\n\n\nSend bug reports from your web app to Pivotal Tracker<\/h2>\n\n\n\n
If you\u2019re working on a new website or web application, you might end up using Pivotal Tracker as your project management tool. While developing and testing your site, there might be a couple of bugs and issues which need to be fixed and need some further attention in your Pivotal Tracker project.<\/p>\n\n\n\n
With the Usersnap bug tracker integration for Pivotal Tracker<\/a>, you can embed a little feedback widget on your websites. This feedback widget allows you and your testers to report bugs or simply leave some feedback.<\/p>\n\n\n\n![\"bug](\"https:\/\/usersnap.com\/blog\/wp-content\/uploads\/2015\/09\/bug-tracking-pivotal-tracker-integration.jpg\")
<\/figure>\n<\/div>\n\n\nSee the full guide on how to send bug reports from your website to Pivotal here.<\/a><\/p>\n\n\n\nLabeling is a time-saver<\/h2>\n\n\n\n
When working inside your Pivotal Tracker projects, you have different kinds of fields which need to be filled out. From Story types, to points, states, owners, and so on.<\/p>\n\n\n\n
There\u2019s an additional field which I truly recommend to make use of. Those are called Labels.
Labels are a great way to cluster and segment your stories. Having a lot of stories in place, you might want to filter out certain stories for certain use cases.<\/p>\n\n\n\n
Therefore I recommend to make use of the following labels:<\/p>\n\n\n\n
\n- blocked<\/li>\n\n\n\n
- ideas<\/li>\n\n\n\n
- needs-owner<\/li>\n\n\n\n
- needs-design<\/li>\n\n\n\n
- needs-development<\/li>\n\n\n\n
- needs-discussion<\/li>\n\n\n\n
- needs-customerfeedback<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n
Try Usersnap for Bug Tracking<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\nWrapping it up.<\/h2>\n\n\n\n
Wow. That was quite a lot. I know it may sound overwhelming in the beginning but once you get settled with Pivotal Tracker, joy and satisfaction will take over. And there are definitely way more benefits to using Pivotal Tracker than those I\u2019ve already shown you in this blog post.<\/p>\n\n\n\n
Are you thinking of making the switch to Pivotal Tracker? Let us know in the comments or on twitter<\/a>!<\/p>\n\n\n\n
Here\u2019s my personal answer.<\/p>\n\n\n\n
Pivotal Tracker<\/a> is a collaborative & lightweight project management tool developed by Pivotal Labs, a company whose expertise in agile development is widely known.<\/p>\n\n\n\n The main difference Pivotal Tracker has to other project management tools are their so-called \u201cstories\u201d. Pivotal Tracker focuses entirely on these stories.<\/p>\n\n\n\n A story is basically a description of a new feature, bug or simple change request, considered from the perspective of the user. This not only helps you to prioritize your stories, but also lets you focus on what\u2019s important for the user.<\/p>\n\n\n\n Pivotal Tracker projects consist of 4 different lists: icebox, backlog, current, and done.<\/strong><\/p>\n\n\n\n On the one hand, this workflow is pretty basic, and on the other hand, it\u2019s lean and helps you to focus on your real work.<\/p>\n\n\n\n As mentioned, stories are the core heart of Pivotal Tracker. Pivotal divides stories into the following sub-categories:<\/p>\n\n\n\n The icebox seems kind of new if you\u2019re coming from other project management tools and using Pivotal Tracker for the first time. However, the principle of the icebox is simple and it\u2019s the place to start a new project.<\/p>\n\n\n\n The icebox is the place where you enter all your features and ideas at the project start as well as throughout the project itself.<\/p>\n\n\n\n This means that any new story goes to the icebox first. The product owner can then decide and prioritize.<\/p>\n\n\n\n The backlog should be your real workspace. Stories which you and your team would like to tackle first are moved from the icebox to the backlog. The higher the story is in the backlog list, the sooner you\u2019ll start working on it.<\/p>\n\n\n\n Pretty simple, huh?<\/p>\n\n\n\n Story statuses might sound a bit confusing at first, since they differ a bit from other project management tools. But you\u2019ll soon benefit from the advantages that come with the following statuses.<\/p>\n\n\n\n When a story entered by your project team into the icebox gets \u201capproved\u201d and it is concluded that someone will be working on it, it will be moved to the backlog.<\/p>\n\n\n\n As soon as a story is listed in the backlog, it gets the status: Start. If, for example, a developer starts working on that story, he or she will press the start button and the story will automatically be moved to the Current list and get the status: Finish.<\/p>\n\n\n\n When the developer finishes his task the status will change to Deliver. Once a story has been delivered, it can move up to the story acceptance (Accept vs Reject).<\/p>\n\n\n Once a story is rejected, the status will move back to \u201cre-start\u201d, allowing your developers or designer to re-work the story tasks. If the story gets accepted by the product owner, it will be moved automatically to the \u201cdone\u201d list.<\/p>\n\n\n Pivotal Tracker offers you a comprehensive search interface which allows you to search and filter for different stories. This comes in quite handy when working on a large project with a lot of people involved and a lot of created stories.<\/p>\n\n\n\n Searches are performed across all story text (e.g. title, description, comments, tasks, requestor, owner, and a lot more).<\/p>\n\n\n\n I\u2019d recommend to check out the following search queries:<\/p>\n\n\n\n <\/p>\n\n\n\n Further ideas for your search can be found in this help section of Pivotal Tracker<\/a>.<\/p>\n\n\n\n By default, all projects are private. This means that those projects are only accessible to you and to the users which you explicitly invite.<\/p>\n\n\n\n On the other hand, public projects are visible to anyone, in read-only mode. Importantly, public projects also appear on the public directory<\/a> of Pivotal Tracker. So if you\u2019re working on an open-source project or something NPO- or NGO-related, public Pivotal Tracker projects can be the way to go. (Transparency FTW \ud83d\ude09 )<\/p>\n\n\n So when starting out with Pivotal Tracker and creating and working on your first stories, you\u2019ll soon notice in-app notifications<\/a> as well as email notifications coming in.<\/p>\n\n\n\n Decide wisely whether you want to be notified via email on every created story or whether getting notified only of relevant state changes is already sufficient for you. If you do not want your inbox be messed up with notifications, I\u2019d recommend making use of in-app notifications instead of getting all notifications.<\/p>\n\n\n\n Both settings can be found in Profile > Notification Settings<\/strong>.<\/p>\n\n\n\n As mentioned before, stories should always be user-centric and therefore start with \u201cUser can\u2026\u201d. However, a story is not only a feature request from the user perspective, but also a deliverable which needs to be done.<\/p>\n\n\n\n it is therefore recommended that customers (or project managers) AND developers write those stories together.<\/p>\n\n\n\n Pivotal Tracker allows you to estimate the amount of effort needed to finish each story.<\/p>\n\n\n The default point scales are 0, 1, 2, 3. Pivotal Tracker allows you to create your own custom point scales for your projects. Simply go to your project settings > iterations and velocity<\/em><\/strong><\/p>\n\n\n No matter if you\u2019re using the default point scale or customer ones, do not overuse the maximum point number. Reserve those max. ratings for real high priority issues or as Joseph Moore from Pivotal Labs puts it<\/a>:<\/p>\n\n\n\n If you\u2019re working on a new website or web application, you might end up using Pivotal Tracker as your project management tool. While developing and testing your site, there might be a couple of bugs and issues which need to be fixed and need some further attention in your Pivotal Tracker project.<\/p>\n\n\n\n With the Usersnap bug tracker integration for Pivotal Tracker<\/a>, you can embed a little feedback widget on your websites. This feedback widget allows you and your testers to report bugs or simply leave some feedback.<\/p>\n\n\n See the full guide on how to send bug reports from your website to Pivotal here.<\/a><\/p>\n\n\n\n When working inside your Pivotal Tracker projects, you have different kinds of fields which need to be filled out. From Story types, to points, states, owners, and so on.<\/p>\n\n\n\n There\u2019s an additional field which I truly recommend to make use of. Those are called Labels. Therefore I recommend to make use of the following labels:<\/p>\n\n\n\n <\/p>\n\n\n Wow. That was quite a lot. I know it may sound overwhelming in the beginning but once you get settled with Pivotal Tracker, joy and satisfaction will take over. And there are definitely way more benefits to using Pivotal Tracker than those I\u2019ve already shown you in this blog post.<\/p>\n\n\n\n Are you thinking of making the switch to Pivotal Tracker? Let us know in the comments or on twitter<\/a>!<\/p>\n\n\n\nSimple workflows are always the best<\/h2>\n\n\n\n
Stories: Features, Bugs, Chore, Release<\/h2>\n\n\n\n
\n
Make use of the icebox<\/h2>\n\n\n\n
Clean up your backlog<\/h2>\n\n\n\n
The Pivotal Tracker workflow<\/h2>\n\n\n\n
<\/figure>\n<\/div>\n\n\n<\/figure>\n<\/div>\n\n\nMake use of the search & save search queries<\/h2>\n\n\n\n
\n
<\/figure>\n<\/div>\n\nTry Usersnap for Bug Tracking<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n
Working on public projects?<\/h2>\n\n\n\n
<\/figure>\n<\/div>\n\n\nBe aware of notifications<\/h2>\n\n\n\n
Write stories together<\/h2>\n\n\n\n
Don\u2019t overuse max-points<\/h2>\n\n\n\n
<\/figure>\n<\/div>\n\n\n<\/figure>\n<\/div>\n\n\n\n
Reserve them for \u201cOMG\u201d stories.<\/h3>\n<\/blockquote>\n\n\n\n
Send bug reports from your web app to Pivotal Tracker<\/h2>\n\n\n\n
<\/figure>\n<\/div>\n\n\nLabeling is a time-saver<\/h2>\n\n\n\n
Labels are a great way to cluster and segment your stories. Having a lot of stories in place, you might want to filter out certain stories for certain use cases.<\/p>\n\n\n\n\n
Try Usersnap for Bug Tracking<\/h2>Try Usersnap Now<\/a><\/div>\n\n\n\n
Wrapping it up.<\/h2>\n\n\n\n