I wrote some time ago about how you can manage a fixed priced project lifetime with Visual Studio online.
There I mentioned that status of tasks should be migrated to the upper levels of user stories and features like this (in short):
- when a task becomes active, the parent story should also become active if it was not active already; when a story becomes active, the parent feature should also become active if it was not active already, similarily;
- when the last task of a story becomes closed, the story becomes resolved; when the last story of a feature becomes resolved, the feature also becomes resolved;
- when a story is tested, it status changes to closed; when the last story of a feature becomes closed, the feature also becomes closed;
- when reopening a story, the parent feature also reopens, and at least one child bug or task (possibly newly created) becomes active.
I also talked there about using estimated and remaining effort values (in hours) for tasks, to automatically get the computed at story level. But of course, you can also report hours by adding time sheet entries under a task.
Finally, I would just like to add that when you commit and push changes (or submit change sets) as results of implementation tasks, you should also:
- link them to the associated user stories;
- some people would also link them to tasks (with TFS this also proposes setting the status of the task from Active to Close, but not with GIT – at least not right now); this is fine, but usually not necessary: when you want to see how a thing was implemented you check it from the story level, not from the implementation task;
- the same applies to the feature level: usually features are used just for grouping stories, and in my opinion (gathered from my experience) you’d rarely want to see a large list of commits that make up a complex functionality (you’d check individual stories instead), so I think you can skip linking changes to features as well.