A story is a small feature. It’s a concise description of something a user can do, e.g., “Member can update their profile.”
We often use a three-part format for user stories:
As a [user role],
I want to [goal],
so that [reason].
A user role is a part played by a user, e.g., Admin, Visitor, Member.
Story points are the currency of Agile and they are used for estimating User Stories. These estimates give you an idea of the relative size of different User Stories. You can use this information when making decisions about prioritization.
In the initial proposal we sent you, we gave an estimate of the effort required on our part to complete a Story Point's worth of features (based on comparable prior projects). This number is an estimate, as every project is a little different. A Story Point is typically 1-2 hours of work. As your project progresses, we'll have actual metrics showing how much effort is required to deliver a Story Point's worth of features on your project. We'll use that information to project the remaining cost of your project and we'll share that information with you in your project status report every week.
If you want to think in terms of dollar amounts, you can always ask your project manager what the current cost per point is on your project.
To add a Story:
Your story has been added to the Icebox, which is a place for holding stories that you are not ready for us to work on yet.
When you’re ready for us to start work on a story, drag it from the Icebox to the Backlog. The stories that will get tackled that week automatically move from the Backlog to the Current column.
Note: After a story has been estimated, a “Start” button will appear on the right side of the story. The client should NOT press the “Start” button. The “Start” button is for developers to click on when they start the story.
An iteration results in one or more bite-sized but complete packages of project work that can perform some tangible business function.
Our default iteration period is usually one week.
Once you’ve added a couple of stories to the backlog, you can prioritize them by dragging the highest priority items to the top of the column.
When we deliver a story, Pivotal Tracker will email you telling you that the story’s been delivered and that you should review it.
Labels can be used to tag or categorize stories. Labels are mostly for use by Singlebrook, but we’ll let you know if there are specific labels you should be putting on your stories.
You can comment on a story by expanding the story and entering your comment in the comment box. You can also reply to any email you receive from Tracker about a story to comment on that story.
When you comment on a story, anyone involved in that story (by being the Requestor, Owner, or having commented previously) will receive an email containing your comment.
A project’s velocity is a measure of how many story points are being completed and accepted per iteration. Tracker looks at the last few iterations to see how fast we’re moving and to predict our future schedule.
Create a new story in the Icebox: Describe the story from the user's perspective. Supporting files (mockups, spec documents, etc.) can be attached to the story. The client is the requester of the story, but there is no owner until work begins.
Estimation: Singlebrook will give the story an estimate.
Approval: The client can drag the estimated story from the Icebox to the Backlog to give us approval to work on the story. Stories in the Backlog can be prioritized by dragging the higher-priority ones to the top of the list.
Work begins: Developers begin work starting at the top of the Current column and then flow into the Backlog column if the stories are finished ahead of schedule. When a developer starts a story, they automatically become the owner of the story.
Clarification: Singlebrook and the client will discuss the story as necessary to make sure we're on the same page. This can happen on the phone or by commenting on the story in Tracker, in which case an email will go out to let everyone involved know that there's a new comment. The story's description will be updated as necessary to reflect our shared understanding of the work to be done.
Finished: When we're done working on the story, we'll mark it Finished. Since we do most of our development on our own workstations, the client won't see the changes until we roll them out to your staging site. We'll Deliver the story, and the requestor will get an email asking them to review the work.
Acceptance: After reviewing and testing the work, the requestor will Accept or Reject the story. Rejecting a story is fine, but the client should make sure to leave comments explaining why the story was rejected. If the story's been Rejected, we'll Restart it, make adjustments as necessary, and return to the “Finished” step.
As a client, your responsibilities in Tracker are:
Check out the HELP link at the top of the page when you’re in Tracker, especially the Getting Started section.
The Wikipedia page provides a pretty comprehensive overview of Agile: http://en.wikipedia.org/wiki/Agile_software_development
Visit https://www.pivotaltracker.com/help or speak with your project manager.