Skip Ahead to:<\/strong><\/p>\n Overview<\/a><\/p>\n Navigation<\/a><\/p>\n Prioritizing and Estimating User Stories<\/a><\/p>\n Add ToDo to a User Story<\/a><\/p>\n Tracking User Story\/ ToDos Progress<\/a><\/a><\/a><\/p>\n Creating Test Cases for the User Story<\/a><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 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. <\/a>Team member(s) assigned to each of the ToDo can independently work on it.<\/p>\n Navigate to the breadcrumb at the top and hover over the Project name, expand the\u00a0Execute<\/strong>\u00a0module, and select\u00a0User Stories<\/strong>.<\/p>\n 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.<\/p>\n User stories are ranked (enter the rank for a user story), estimated (enter the Planned Estimates for a user story), and tagged to <\/a>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).<\/p>\n To add the new ToDo, click the ADD<\/strong> ToDo button and add a ToDo to the user story.<\/p>\n In short, the ideal way is to break a user story into ToDos.<\/p>\n Notes:<\/strong><\/p>\n Do not close\/delete any ToDo that is not completed in the current iteration.<\/p>\n<\/li>\n 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.<\/p>\n<\/li>\n<\/ul>\n 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\u2019 Inboxes and they can enter their efforts for each ToDo at the end of the day.<\/p>\n 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.<\/p>\n Assumptions while logging efforts<\/b><\/p>\n In this approach, the remaining effort for ToDos are reported (Ideally, on a daily basis during the daily scrum).\u00a0 This can be achieved by double-clicking on the time log cell for any day and changing the \u2018Daily Remaining Hours\u2019 to the required value.<\/p>\n 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\u2019 will appear as 10 hours in the timesheet.<\/p>\n This daily remaining hour value gets stored and is used for generating the Burndown charts.<\/p>\n Team members, who report remaining hours on a daily basis, can also change the weekly \u2018Rem Hrs\u2019 value visible in the timesheet, without any double clicks. The changes made to that cell are considered as the \u2018Daily remaining Hours\u2019 for that day.<\/p>\n At the beginning of a ToDo, ‘Remaining hrs\u2019 is shown as equal to the ‘Estimated Effort\u2019. 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.<\/p>\n For example – ‘Remaining Hrs\u2019 was updated on 1st<\/sup>\u00a0January as 100 hours and no timesheet was updated between 2nd<\/sup>\u00a0January to 5th<\/sup>\u00a0January, it will show ‘Remaining Hrs\u2019 as 100 for all dates in between.<\/p>\n The team member updates the ‘Remaining Hrs\u2019 for past dates as well, the application will use the recent ‘Remaining Hrs\u2019 entry for all tracking\/metrics calculations. (Note: This functionality is governed by access rights control.)<\/p>\n Notes<\/b>:<\/p>\n There could be certain projects which may have recently implemented agile methodologies in their projects and are not yet comfortable in reporting an accurate \u2018Remaining Hours\u2019 on a daily basis and are still comfortable with \u2018Actual Effort\u2019 reporting. Such users need to consider the points below:-<\/p>\n 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 \u2018Daily Remaining Effort\u2019 is also captured implicitly, based on the progress of ToDos in terms of actual effort.<\/p>\n However, the user should fill the timesheet in a sequence.<\/p>\n Projects that follow agile methodology and also need actual efforts for billing purposes can report time in the following ways: –<\/p>\n Team members should regularly fill \u2018Daily Remaining Hours\u2019 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.<\/p>\n <\/a>For example, as Daily Remaining Hours is not filled for 16 July, the system will take the value of 40 (filled for 15 July).\u00a0 Similarly, for 18-July it will consider 41 which was filled for 17-July.<\/p>\n Earlier, if a user was assigned to a to-do and due for some reason the user couldn\u2019t 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.<\/p>\n But now the Project Manager has the special privilege to Close or Reopen the to-do irrespective of logged efforts.<\/p>\n It can be done by clicking the following buttons:<\/p>\n 1)\u00a0Close button<\/b>: This button allows forceful closure of to-dos. Once the to-do is closed the to-do status changes to complete.<\/p>\n 2)\u00a0Reopen button<\/b>: Reopening a to-do means that a to-do\u2019s current status will be marked to be open so that the to-do can be allocated to a different user.<\/p>\n Preferences<\/b>\u00a0to see Close and Reopen buttons:<\/p>\n Note<\/b>: After setting the preferences, you need to open the agile project and set the timesheet wizard.<\/p>\n <\/a>Now, go to User Story, and you will see the Close <\/strong>and Reopen<\/strong> buttons.<\/p>\n 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.<\/p>\n 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.<\/p>\nOverview<\/h2>\n
<\/a>Navigation<\/h2>\n
Prioritizing and Estimating User Stories<\/h2>\n
Add ToDo to a User Story<\/h2>\n
\n
![\"\"](\"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/wp-content\/uploads\/2022\/04\/ToDos.jpg\")
<\/a><\/p>\n<\/a>Tracking User Story\/ ToDos Progress<\/h2>\n
\n![\"\"](\"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/wp-content\/uploads\/2022\/04\/TimeEntry.png\")
<\/a><\/p>\n\n
\n
Only by \u2018Remaining Effort\u2019<\/h3>\n
\n
Only by \u2018Actual Effort\u2019<\/h3>\n
\u2018Remaining Hours\u2019 and \u2018Actual Effort\u2019<\/h3>\n
\n
Force Closing or Reopening of ToDo’s<\/h2>\n
![\"\"](\"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/wp-content\/uploads\/2022\/04\/Close.png\")
<\/a><\/p>\n![\"\"](\"https:\/\/www.nimblework.com\/knowledge-base\/nimble\/wp-content\/uploads\/2022\/04\/Reopen.png\")
<\/a><\/p>\n\n
Creating Test Cases for the User Story<\/h2>\n
\n