In this article, we will help you to understand the marketing templates and menus related to it.
|
Skip Ahead to: Prioritizing and Estimating User Stories |
Overview
Typically, the product owner defines the user stories and scopes an iteration where the user stories are linked to the iteration. When the development team starts working on the user stories according to the schedule, they can break the user stories down into granular ToDos for easy execution. Team member(s) assigned to each of the ToDo can independently work on it.
Navigation
Navigate to the breadcrumb at the top and hover over the Project name, expand the Execute module, and select User Stories.
Prioritizing and Estimating User Stories
When the user story is routed to the Product Owner, it is the primary responsibility of the Product Owner to determine what work is of the highest priority and will yield the most business value, and so prioritize the Product Backlogs accordingly.
User stories are ranked (enter the rank for a user story), estimated (enter the Planned Estimates for a user story), and tagged to an iteration (select the Iteration from the Iteration List for a user story) and in turn to project releases (as Iterations, when created, can be tagged to a release).
Add ToDo to a User Story
To add the new ToDo, click the ADD ToDo button and add a ToDo to the user story.
In short, the ideal way is to break a user story into ToDos.
Notes:
-
Do not close/delete any ToDo that is not completed in the current iteration.
-
ToDos included in the iteration should be in between the Iteration Start and Iteration End dates. There is no restriction of adding ToDo only between the Iteration start date and the Iteration End date. The Burndown chart will show data only starting from the iteration date i.e. even if a member has a certain ToDo included in the Iteration that starts prior to the Iteration start date, the Iteration Burndown chart will show data as-is from the iteration start date.
Tracking User Story/ ToDos Progress
While the team works on their daily ToDos, it is important that their efforts are captured which subsequently will update the status of ToDos. The ToDos that are assigned to the team members are displayed in the team members’ Inboxes and they can enter their efforts for each ToDo at the end of the day.
In the ToDo list, click the Timer icon to enter time logs for that ToDo. In the time log pop-up window, you can enter billable hours, remaining hours, and the Timesheet cell-level comments.
There are three ways of reporting the progress of the ToDo, for an Agile project.
- Remaining Effort’ only ( True Agile way)
- Both Actual and Remaining Effort
- Only ‘Actual Effort’
Assumptions while logging efforts
- Agile teams are fairly mature to report accurate actual/ remaining effort and hence would do so judiciously in the provided cells after reviewing the time entry (Actual/Rem.)
- The ‘Remaining Effort’ would typically reduce as per the actuals reported against a ToDo. Though they may not be in equal proportion always, do correlate. Hence system defaults it in proportion to the actual entered. Since both cells are together, it would bring it to users’ attention instantly to check it and revise, only if required, and ‘Save’ the time entry.
- Agile time reporting is typically done on a daily basis, so we are only focusing on just two cells (Actual and Remaining Effort) at a time for the user to verify and hence lesser prone to accidental mistakes.
Only by ‘Remaining Effort’
In this approach, the remaining effort for ToDos are reported (Ideally, on a daily basis during the daily scrum). This can be achieved by double-clicking on the time log cell for any day and changing the ‘Daily Remaining Hours’ to the required value.
The Remaining Hours entry for ToDos in a timesheet reflects the recently entered hours. For example, in the time log for 1st January, if the remaining hours are entered as 20 and for 2nd January remaining hours are entered as 10, ‘Remaining Hours’ will appear as 10 hours in the timesheet.
This daily remaining hour value gets stored and is used for generating the Burndown charts.
Team members, who report remaining hours on a daily basis, can also change the weekly ‘Rem Hrs’ value visible in the timesheet, without any double clicks. The changes made to that cell are considered as the ‘Daily remaining Hours’ for that day.
At the beginning of a ToDo, ‘Remaining hrs’ is shown as equal to the ‘Estimated Effort’. In the time log, if the Remaining Hours field is empty for any day, it is updated automatically with the recently entered ‘Remaining Hours’ entry.
For example – ‘Remaining Hrs’ was updated on 1st January as 100 hours and no timesheet was updated between 2nd January to 5th January, it will show ‘Remaining Hrs’ as 100 for all dates in between.
The team member updates the ‘Remaining Hrs’ for past dates as well, the application will use the recent ‘Remaining Hrs’ entry for all tracking/metrics calculations. (Note: This functionality is governed by access rights control.)
Notes:
- When ToDos are marked ‘Done’, the remaining hours from the date where no time is entered are considered to be zero. For e.g. if there is ToDo which starts from 01-05-12 to 07-05-12 and daily remaining hours are entered for the date 01-05-09 as 20 Hrs and 03-05-12as 15 Hrs. It will display as 15 hrs for the rest of the days (until the user enters ‘Remaining Hrs’ on any of the following days).
- Now when the user marks this ToDo as done, the Remaining hours from the date where no time is saved will be considered 0.
- Further, if the user marks this ToDo as Received, it will revert back to what it was prior to marking it as ‘Done’. In our above example, it will again show as 20 for the remaining period.
Only by ‘Actual Effort’
There could be certain projects which may have recently implemented agile methodologies in their projects and are not yet comfortable in reporting an accurate ‘Remaining Hours’ on a daily basis and are still comfortable with ‘Actual Effort’ reporting. Such users need to consider the points below:-
A user may simply update the actual effort against the ToDo in the timesheet and the remaining hours get reduced by that value as the user logs the time for each day. This ensures that ‘Daily Remaining Effort’ is also captured implicitly, based on the progress of ToDos in terms of actual effort.
However, the user should fill the timesheet in a sequence.
‘Remaining Hours’ and ‘Actual Effort’
Projects that follow agile methodology and also need actual efforts for billing purposes can report time in the following ways: –
- Using the earlier way of double-clicking pop-up entry:- Once a team member enters ‘Actuals’, the ‘Remaining Effort’ is reduced by the extent of actual and defaulted as the current remaining effort for the ToDo. The team member needs to validate it and make the required change in the remaining effort, before finally saving the time log.
- The team member may enter the actual effort directly, which will show the current remaining effort, and then change the remaining effort to reflect the correct value for the ToDo by modifying the ‘Rem Hrs’ cell. Assuming daily time reporting the ‘Rem Hrs’ cell value change gets stored as today’s Remaining Hour value.
Team members should regularly fill ‘Daily Remaining Hours’ for ToDos: If there is no time entered for daily remaining hours for any day, the system will use the time logged in for the last filled-in day i.e. for any day if daily remaining hours are not filled in the timesheet, it will take the value of the last date filled in remaining hours.
For example, as Daily Remaining Hours is not filled for 16 July, the system will take the value of 40 (filled for 15 July). Similarly, for 18-July it will consider 41 which was filled for 17-July.
Force Closing or Reopening of ToDo’s
Earlier, if a user was assigned to a to-do and due for some reason the user couldn’t continue on that to-do, then the to-do use remained in open status. The project manager did not have the option to close it.
But now the Project Manager has the special privilege to Close or Reopen the to-do irrespective of logged efforts.
It can be done by clicking the following buttons:
1) Close button: This button allows forceful closure of to-dos. Once the to-do is closed the to-do status changes to complete.
2) Reopen button: Reopening a to-do means that a to-do’s current status will be marked to be open so that the to-do can be allocated to a different user.
Preferences to see Close and Reopen buttons:
- Go to Administration > Access Configuration and under Workspace select Working Project.
- Under Execute > Task Plans, set Complete/ Reopen to Yes.
- Under Execute > User Stories set Complete/ Reopen to Yes.
Note: After setting the preferences, you need to open the agile project and set the timesheet wizard.
Now, go to User Story, and you will see the Close and Reopen buttons.
Creating Test Cases for the User Story
After or even while the user story is being worked upon, a tester can create test cases to verify and validate the working of the feature/enhancement. Creating test cases from the user story itself ensures that relevant test cases are created for a user story.
Once the ToDos in the user story is completed, the developer can keep a track of defects and whether all defects related to the user story were fixed or not.