開発プロジェクトを進めていく上でタスクの整理はとても重要です。（ので今後も追記していきます）
Visualstudio.comを利用していますが、他の類似開発プロジェクト管理サービスでも同じことが言えるで参考にしてください。
開発するモノ＝Tasg（もしくはBug改修項目）、が最小粒度のものとしたときに、それを束ねるStory、さらにそれを束ねるような形でFeature, そしてEpicと区分することによって開発側もプロマネ側も円滑な意思疎通をすることができます。
各区分
こうじゃないとダメ！というものはありませんが、基本概念として下記を参考にしてください。
Epic
巷でマイルストーンと言われるものはEpicと言っていいでしょう。Epicのタイトルは「正式版リリース」という類。
Feature
直訳すると機能区分みたいなものです。基本1-3回のsprintに分けられる粒度です。Featureのタイトルは「在庫管理機能搭載」という類。
Story
開発者じゃない人がみてもわかるような機能区分です。1sprintで完了する粒度です。 Storyのタイトルは「在庫管理ができるようになる」という類。
Task or Bug
こちらは完全に開発マターの作業単位です。タイトルは開発にお任せしますが、見積もりの工数はタスクの積み上げなので、一度の作業で終わる単位に分解することをお勧めします。
担当
一般的な開発プロジェクトは下記の構成
- 依頼主（ビジネス側）
- 依頼一次受け・受取窓口（プロマネ）
- 開発（開発＋テスター）
Epicは全員が認識するべき項目で、日付が決まっています。
プロマネは、Epicにまつわる要件(requirement = Features)を整理し、そのFeaturesをStoryに分解して全員と認識をすり合わせます。
それを理解した開発者もしくは開発責任者は各Storyに対して必要なTaskを入れ込み、各Taskの工数を見積ます。積みあがった数字をStoryに、Featureに、そしてEpicに追加していきます。
テスト等を通じてあがってきたバグは一旦テスト実行日を1StoryレベルでまとめてテスターがBugとして起こします。TaskレベルになっているBugをStoryレベルに開発責任者が仕分けをしてアサインをします。アサインをされたら必ず見積時間を確認するようにします。
備考
サービスの場合、リリース番号の管理も同じようなコンセプトもっています。 たとえばVersion 1.2.3.4 となるときは、 2=Epic, 3=Feature, 4=Sotryといった感じに上げていく。リリース時に新しいFeatureはなくてStoryレベルのみの更新であれば 1.2.3.5。Featureレベルの更新も含む場合は1.2.4.0といった具合に。