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 development 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 developer what the current cost per point is on your project.

Examples

• At the beginning of a week-long iteration, you might have a choice between prioritizing one 10-point story or three 3-point stories for that week. Completing either set of stories will take about the same amount of time.
• If you're working with a relatively fixed budget, but want to add a 6-point User Story to the Backlog, you can keep your project on budget by removing another 6-point User Story (or two 3-point User Stories).

To add a Story:

• Either click the “Add Story” button or hit the “A” key on your keyboard.
• Add a title and description to your story. Make sure to use the 3-part story format if possible.
• Click “Save”.

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.

• The Icebox holds stories that you are not ready to schedule to be worked on, but may want to in the future.
• The Backlog holds scheduled stories that will be worked on next after the current stories are complete.
• Current holds stories that are being worked on in the current weekly iteration.

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.

• The developers will estimate how many story points it will take to complete a story.
• Stories are usually estimated in the Icebox.
• If there are more than 5 unestimated stories in the Icebox, you should label the ones that you wish to have estimated with "estimate" before your weekly project meetings.
• Once the story has been estimated, the number of story points will show up on the left side of that story.
• Please see the FAQ: What is a Story Point? for more information about how points work.

Located at the top of the Icebox in Pivotal Tracker, you'll find your project budget chore. This will give you an estimated price for the story based on the historical hours per point average of the project. Pivotal Tracker calculates this by multiplying the estimated number of points by the hours per point (HPP), and multiplying the total by the standard Singlebrook billing rate.

ex: 3 point estimated story x 2 hours per point x $150 = $900

These are meant to give you an idea of what the story will cost based on estimations, and may not reflect the exact total.

When we deliver a story, Pivotal Tracker will email you telling you that the story’s been delivered and that you should review it.

• You go to your staging site to test the story.
• If it meets your requirements, you click on the accept button. If it doesn’t meet your requirements, you click on the reject button and then add comments about how to improve the story. Clients should have no fear about rejecting a story. This is an important collaborative stage in the process, and it is important that the story meets the client's needs as closely as possible.
• In general, the “Accept” and “Reject” buttons are the only buttons that a client should use. The other buttons are for developer use only.

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.

• Features are for new work. This might be something totally new, or a change to some existing functionality that has already been accepted as complete by the client. If you're asking for a change on a story that hasn't been accepted yet, it should be entered as a comment.
• Bugs should be used if previously accepted work is not behaving as expected. If you find a bug in functionality that has already been Accepted, please create a new Bug story and put it in the Backlog. If you find a bug in a story you're testing, please Reject the story and add the bug as a comment. For all bugs, please include as much detail as you can about what you were doing at the time so that we can easily reproduce the problem.
• Releases are for marking major releases. These are the only type of stories that can have due dates. Pivotal Tracker will show you if we're on track to hit a due date by coloring the release blue or red.
• Chores are for either technical, behind-the-scenes work, or are reminders for information we need from the client.

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.

1. 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.
2. Estimation: Singlebrook will give the story an estimate.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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:

• Clicking the Accept or Reject buttons on stories we've finished after you've tested the feature in question. The rest of the buttons (Start, Finish, Deliver, Restart) are for developer use only.
• Filing bug reports. If you find a bug in functionality that has already been Accepted, please create a new Bug story and put it in the Backlog. If you find a bug in a story you're testing, please Reject the story and add the bug as a comment. For all bugs, please include as much detail as you can about what you were doing at the time so that we can easily reproduce the problem.
• Responding to questions we ask. If we post a comment with a question for you on it, please reply to the email. Tracker will attach your response to the story in question and will notify anyone who's working on that story.

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: http://en.wikipedia.org/wiki/Agile_software_development

Visit https://www.pivotaltracker.com/help or speak with your lead developer.