Sean's dashboard

Sean replied on August 25, 2009 17:12 to the question "How do I access the My Work panel?" in Pivotal Labs:

Bill, it's the second option under the View menu.

Sean replied on August 25, 2009 17:03 to the problem "Our stories are not set to "done"." in Pivotal Labs:

Ton, have you Accepted any of your stories yet? In Tracker there are a number of story states, but only Accepted stories count towards velocity. Also, Tracker doesn't begin counting iterations until your first story is Accepted.

In the current Tracker workflow, the story states are Unstarted (no work done yet), Started (writing code), Finished (code is complete and checked into source control), Delivered (code is deployed to a demo or staging environment), and then Accepted (product manager has seen the story live on demo and approves). Since the story isn't done until the PM accepts the implementation, Tracker doesn't grant velocity points for any story that's not been accepted.

Does that help answer your question or is there something else at work? If you still have questions, can you include a project name or id so we can look at your specific case? You can email it to tracker@pivotallabs.com if you prefer.

Sean replied on August 24, 2009 23:21 to the question "How do I retroactively set the start date for a given iteration?" in Pivotal Labs:

John, I'm not sure I'm understanding your needs completely, so please let me know if this isn't addressing your question.

If you are asking can you set any given iteration's start date, the answer is no. Each iteration starts automatically when the previous one ends. You can select iteration lengths of 1 to 4 weeks and they can start on any day of the week.

If you are asking how to set the start date of your first iteration, the answer is that your first iteration must contain your first Accepted story. A different way of saying that is that once you Accept your first story, Tracker understands the first iteration must be underway and thus backdates Iteration 1 to the closest iteration start day. For example, if you have one week iterations starting on Wednesday, and you accept a story on Thursday, August 20th, the first iteration would begin Wednesday, August 19th. If you accepted your first story on Tuesday, August 18th, the first iteration would had to have begun on Wednesday, August 12th, and Tracker will update to make that true.

The practical upshot is that you can determine your first iteration start by accepting a story and backdating the acceptance date to some day that falls within the time frame you want to be your first iteration.

Does that help?

Sean marked one of undees' replies in Pivotal Labs as useful. undees replied to the question "Why does the Points Breakdown say my 120-day project doesn't have enough data?".

Sean replied on August 24, 2009 18:25 to the question "Why does the Points Breakdown say my 120-day project doesn't have enough data?" in Pivotal Labs:

The project points breakdown chart shows things as they were on each day in the past. Because recalculating the daily story count on the fly is prohibitively computationally expensive, we only display counts for days since we started taking nightly snapshots of project story breakdowns. We just recently added the feature, so there are not yet 30 days of snapshots.

Sean replied on August 21, 2009 20:25 to the question "can you delete story comments in tracker?" in Pivotal Labs:

Currently, no, Mark, story comments cannot be edited or deleted.

Sean started following the idea "Create projects and add members using the API" in Pivotal Labs.

Sean replied on July 31, 2009 19:32 to the problem "Iterations with more than one week are reset every week" in Pivotal Labs:

Ali, have you Accepted any stories yet? If there are no stories that have been Accepted, Tracker assumes the project hasn't started and doesn't begin counting iterations. Essentially, the assumption is that if there is no velocity there is no need to track velocity. This assumption isn't always correct, granted.

Since your iteration start is Thursday, Tracker will start iteration 1 on the Thursday before the first Accepted story. If you accept a test 0-point story today, the iteration 1 start date should stay fixed to last Thursday.

If I've have misunderstood your issue or if that workaround doesn't help, please let us know.

Sean replied on July 30, 2009 19:22 to the problem "How to adjust point scale?" in Pivotal Labs:

Mike is correct, in that the point scales can be changed on the project settings page. However, as Mark mentioned, once you have Accepted stories, there is no way to change the point scale. The reason being Tracker isn't smart enough to convert previous stories to the new scale and preserve the Velocity. Does a 3-point story in the old scale map to a 4 point story in the new scale? 8-point? When you consider the complexity of mapping back and forth between 0,1,2,3 and 0,1,2,4,8 and 0,1,2,3,5,8 there doesn't seem to be a universal solution.

However, as Mark mentioned, if you need to change your point scale you can send email to tracker@pivotallabs.com. Include an explicit mapping of the old scale to the new scale and we will map that change retroactively to the start of your project, preserving your velocity, more or less.

Sean replied on July 30, 2009 19:15 to the problem "Add the ability to put bugs and chores into Delivered and Accepted/Rejected states" in Pivotal Labs:

Joe, right now Tracker has a rigid workflow cycle for Features, Bugs, and Chores. The workflow tracks very well with the needs Pivotal has in developing mostly greenfield websites in small teams. We understand that for larger projects with distinct QA and deployment teams, multiple iterations of Deliver and Accept might be needed. We're still investigating how best to implement configurable workflows.

For your use case, would the ability to add an arbitrary number of Deliver --> Accept repeats be sufficient? Story flow would then be something like Start --> Finish --> Deliver --> Accept [--> Deliver --> Accept]*

Sean replied on July 24, 2009 00:31 to the idea "Ability to edit Members" in Pivotal Labs:

I understand the frustration you have with not being able to manage your users, but in Tracker, an user can be a member of many different projects all managed by different organizations. You are managing your project but not necessarily all the user's other projects. Altering their details would affect all other projects they are on.

In the case of a simple typo, perhaps Tracker could have a 15 minute window for new users where you can still edit the entry, akin to GetSatisfaction's 15 minute comment editing window?

Sean replied on July 23, 2009 23:49 to the problem "Why won't deleting a story in the search results remove it from the search results" in Pivotal Labs:

Aliix, can you just label the stories "won't fix" and put them in the bottom of the icebox?

They are still available and searchable, but clearly tagged won't fix and also not in your backlog.

Sean started following the idea "Position completed Stories at the bottom of Current panel" in Pivotal Labs.

Sean replied on July 10, 2009 21:53 to the question "Where do I document an issue found related to a story? Where do I document an issue not related to a story but is NOT in production?" in Pivotal Labs:

Lindsay, in our workflow, Features are tested when they are in the delivered state, waiting for Accept/Reject. If there's a bug in the feature, the story is rejected and the bug is given as the reason for rejection. The Owner gets a notification that the feature was rejected and they restart the story.

Once a feature has been accepted and the iteration has passed, we don't re-open the feature to reject it. Instead we create a new bug.

Any flaw that can't be addressed by Rejecting a story should be documented as a Bug, I would think.

However, all of these patterns should be adapted to your local conditions, and as long as your team agrees it doesn't matter if you're using Tracker in the same way Pivotal Labs and our clients use Tracker.

I hope that helps!

Sean replied on July 09, 2009 06:07 to the question "What is the distinction between a 'finished' and a 'delivered' story." in Pivotal Labs:

I know we've considered extensible story flows, so that there could be multiple occurrences of Deliver and Acceptance. For instance, you might set it up so the life cycle of a story is Start --> Finish --> Deliver --> Accept/Reject --> Deliver --> Accept/Reject.

In general at Pivotal, with mostly greenfield TDD websites, QA is considered implicit in Acceptance.

Sean replied on July 09, 2009 05:01 to the question "What is the distinction between a 'finished' and a 'delivered' story." in Pivotal Labs:

In Tracker a story is Finished when the code has been completed and checked into source control. A story is Delivered, and thus ready for Accept or Reject, when it has been deployed to a demo environment where the PM can accept or reject the story.

Sean replied on July 08, 2009 19:29 to the problem "I want to see my release!" in Pivotal Labs:

Hiraash, there is currently no way to specify individually custom iteration lengths, and it's not on the feature roadmap as far as I'm aware.

We don't summarize points by release, only by iteration. That's an interesting suggestion and I would encourage you to submit it as a distinct GetSatisfaction idea so we can see how the rest of the Tracker community feels about it.

As for displaying more by release than by iteration, that's not currently possible and again, I'm not aware of short-term plans for that to change. I know it's not ideal, but many people find labels a usable workaround for situations like this. You could label each story in a release with a particular label, and then view a saved search for that label. That would give you a panel with the implicit release-based view, regardless of what was in the Current panel, which will always remain tied to the iteration, not the release.

Search is quite simple now, although you can chain items. It's very analogous to the Gmail search. Your first example would be "type:Bug owner:Hiraash", for instance. There is no date-based searching yet, so your second example is not currently possible. Help, a link in the upper-right nav, has a short description of the terms: http://www.pivotaltracker.com/help#ho...

Sean replied on July 07, 2009 15:40 to the problem "I want to see my release!" in Pivotal Labs:

Hiraash, to your first point, iterations can be 1, 2, 3, or 4 weeks long and can start on any given day of the week, but Tracker assumes that you have consistent iteration lengths and that the iterations always begin on the same day of the week.

On your second point, if you want to put more stories in an iteration than Tracker thinks you can finish, you can enable the Commit Mode in the Project Settings. You can then add as many stories to the current iteration as you like.

I'm not sure I understand your third issue. The Current panel is by definition the stories in the current iteration. If you enable the commit mode, you can override Tracker's automatic pushing and pulling of stories in and out of the Current panel and use Tracker in a bit more Scrum-ish way, if that's your intent.

If I haven't addressed your concerns, please let me know. I feel as though I may have misunderstood a few of your thoughts.

Sean replied on July 07, 2009 02:28 to the question "why do completed stories show up at the top of the current section instead of in "done"?" in Pivotal Labs:

Jacob, only Accepted stories move from Current to Done and only at the end of the iteration. While the iteration is still in progress, all stories stay in current.

Have you had an iteration roll over and you still see the same Accepted stories in the Current panel? Are the stories that are still in the Current panel not Accepted (i.e. are they in Finished or Delivered state?)

I'm happy to take a closer look if you can provide a project name or ID. You can email me at sean AT pivotallabs DOT com if you prefer.

Sean replied on July 07, 2009 02:18 to the question "Team strength and velocity calculation" in Pivotal Labs:

The dashboard is clearly taking the wrong number, without Team Strength. I'll file a new bug with the team about that issue.

Please do follow up here with your velocity after iteration 4 ends. I'm curious to see if at least the velocity in the project settles down.