7. Agile software development refers to a group of software development methodologies that promote iterative development, open collaboration, and process adaptability throughout the life-cycle of the project.
15. Creating Agile project Navigate to Projects, and click the Add Project or Template icon from the toolbar. Select the Agile checkbox, to create an Agile project. The Task Module is automatically set to Digité STaRT.
16. Project Team Setup Click the Invite Team Member icon to allocate resources for your project by searching members based on their availability.
17. Resources can be ‘allocated’ to the project for a specific duration ( Start/End Date), project role and completely or partly. The resources can be ‘Committed’ during allocation or can be ‘Proposed’, and ‘Committed’ later. ‘Allocated Hours’ are calculated based on these resource allocations.
18. Timesheet Setup Run the Timesheet Setup Wizard to enable timesheet entry for the team members.
19. Timesheet Setup Wizard The timesheet tracking mode. For Agile projects is always ‘Remaining Hours’. Leave the check box unchecked as it is not applicable for Agile projects. Select this checkbox to consider the time logged as billable hours to the project. Select this checkbox for always having project creator to approve the timesheet at the posting stage of the timesheet approval workflow. For other screens in the wizard, refer to the Timesheet Training for detailed instructions.
31. Iterations : Resource Capacity Definition Enter resource capacity or copy from earlier sprints. You can compare the Resource Capacity with the Iteration Capacity.
32. Iteration Scope Planning Click to link existing user story to an iteration. Click to add new user story to an iteration. Click to remove user story from an iteration.
33. Story Execution :- Adding Task to a User Story Once an iteration begins, resources can create their own ‘Tasks’ from the user story assigned to them.
34. Story Execution: Logging Efforts in Timesheet Double-click the timelog cell and enter the time along with comments in the Timelog Details window.
35. Story Execution: Creating Test Cases for the User Story Test cases & Defects can also be linked to the user stories.
37. Task Tracking Customize or create Table Views to select required columns for tracking the progress of the tasks. Similarly, the Tasks module displays the tasks in hierarchical list.
38. Test Execution Create test units or link existing test units to the user story. From Test Management > Test Events, execute test units.
39. Defect Tracking When test units linked to a user story fails, you can raise defects which will be associated to the test unit. Link these defects to the user story. You can also create new defects from the Defect section.
41. Agile Reports To view the detailed progress, navigate to Project >> Project Monitoring >> Report List. Click the required report under Agile Reports.
42. Iteration Burndown Chart Displays the tendency of the sprint progress of remaining work to do at the end of each passing day.
43. Release Burndown Chart Displays the release progress with remaining work in the release relative to the release schedule.
44. Iteration Velocity Report Helps to determine how much work the team can tackle in the next sprint by displaying story points completed in each sprint.
45. Release Cumulative Chart Displays the iteration-wise cumulative estimates of the user stories to track the progress of users stories based on the change in their state.
46. Iteration Cumulative Chart Provides the cumulative estimates of story states to understand how the iteration has progressed.
47. Team Status Report Displays the status of tasks completed by the project team members and highlights the comparison between planned effort and individual resource capacity.
48. Iteration Status Report Displays the details of selected iteration drilled down to the user story and task level.
49. Release Status Report Displays the details of selected release drilled further down to the user story and task level.
50.
51. Adding Meeting Minutes To add Meeting Minutes, click Add Meeting Minutes icon. Then populate the mandatory data fields and optional fields as appropriate. To link the minutes to other items, use the Traceability section. Route the Meeting to others using the Workflow feature.
52. Wiki Dashboard Wiki Dashboard with Quick Links, etc. to guide through various wiki pages and other features.
Welcome to Digité’s Agile Project Management training. In this presentation, I’ll walk you through the concepts and features of Digité’s Agile Module to execute and manage a Agile Project.
Let’s get started with the training.
This training course is most suitable and a must for those users of Digité who would be performing either of these functions in their respective projects. Thus, if you can relate yourself to one of these user roles, you should go ahead with this training.
However, I would also recommend that you first complete the training courses that have been listed here before proceeding with this training course. Digité User Interface Introduction Training Digité My Work Workspace Introduction Training Digité Workflow Management Training Digité STaRT Module
By the end of this training, you should be able to understand: Basic concept of Agile Methodology (SCRUM) Agile Project Management features & capabilities Agile specific reports and charts
Let’s get started with the training.
Let’s get started with the training.
These are the different forms of Agile methodologies being implemented of which Digité framework is configued and aligned to the most commonly used form that is the Scrum.
This is the flow in a Scrum-based agile project. The product owner gathers the input from the customers, the team, managers, executives, etc. In the sprint planning meeting, the list of requirements are converted into the product backlog and are prioritized by business value. The team selects from the backlog as much as it can commit to deliver by the end of the sprint. The product backlog is then broken into sprint backlogs by the team limiting the duration of a sprint within 1-4 weeks. After the team works on the backlog, the product passes all the states ( Defined, In Progress, Completed, and Accepted), the shippable product is delivered to the customer. The Sprint Retrospective meeting is held and after the review and retrospective the project is closed.
Let’s get started with the training.
Digité Enterprise support projects that follow Scrum based Agile Methodology. The following representation shows the entities associated when using the Agile Methodology in Digité Enterprise. Product owner collects the requirements from various sources and organizes them as user stories. Collective user stories form the product backlog. The backlog is essential in agile project management as it helps the product owner to plan releases. User stories are assigned to iterations. Iterations are defined for a release as a part of project release planning. Each user story is tagged with following attributes: Rank –The priority of the user story. Planned estimates – Number of Story points-how big is the user story. Planned Estimates get rolled up at Iteration and then to the Release level. State – What is the current status of the user story. User stories are broken down to Tasks, which is at the lowest level of granularity. Tasks are assigned to the team members and an iteration is tracked against the remaining effort defined for a task. Thus in a nutshell, at the lowest level you have Tasks. A User story contains tasks. A List of user stories form an iteration. Iterations form part of a release and multiple releases are part of a project. Since agile management is a part of Digité framework, you can always utilize other modules of Digité to assist you in the project management. You can use Defect Management and Test management to verify and validate your user stories.
Let’s get started with the training. This training gives an overview of various features available in Digité that you can use while creating and managing an agile project. For detailed understanding, you can refer to the feature-specific trainings pointed in various topics.
Creating an agile project is similar to creating any other project in Digité. Navigate to your project listing page and click the ‘Add project’ button as highlighted to create a new project. On clicking Add, the Add Project window appears. Enter appropriate information, and select the Agile Project check box. For Agile-based Projects, Digité uses its own Digité STaRT task module to manage simple task and resource scheduling. Hence, the MS Project option is not available in the Task Module list. Click ‘Finish’ to create an agile project. For more detailed understanding on creating a project, using process templates, etc, go through the Project Creation and Setup training. Select the ‘Agile Project’ checkbox . All functionalities specific to Agile Projects will be available in the project.
After the project is created, you can navigate to the project workspace. The menu options available are same as any other project in Digité . The additional module is the Agile module. This consists of the Iteration and User Story sub modules. After you have created the project, you will have to set up your project team. Navigate to Project >> Project Resources >> Team Members and allocate resources from the Organization by clicking the ‘Invite Team member’ icon. Search the names if you already aware of available resources in the organization. Select the resources from the Search results displayed in the list and click the Move to Selected Team list arrow based on the availability.
By default the ‘From’/’To’ allocation dates for a resource are defaulted to ‘Current Date’ & ‘Project End Date’ respectively. The ‘Booking Type’ field value can be set during allocation and a resource can be tagged as ‘Proposed’, if the allocation is not still sure. For the projects under approval, the value of ‘Booking Type’ always remains as ‘Proposed’, unless the resource gets approved through the approval workflow set. Any new allocation for a resource can also be marked as ‘Proposed/Committed’.
Next, you need to run the timesheet setup wizard for the project. This is a mandatory step for enabling timesheet entry for your project. It is only after running the timesheet setup wizard that the resources allocated to work on various work items in your project will be able to see the relevant items in their timesheets. To start the Timesheet setup Wizard, click the icon from the toolbar.
The first screen of the wizard consists of certain preferences which would determine the behavior of timesheets in your project. First preference setting is about the timesheet tracking mode which is set as Remaining hours. The Application preference can be set to display another option i.e. % Complete, but it recommended to keep the Remaining Hours as the tracking mode for agile projects. The explanation for choosing this mode is provided later in this training when we will be covering the Story Execution section (Logging Efforts in Timesheet). In most of the projects, the checkbox for the second preference setting is left unchecked. (This is not applicable for Agile projects.) Third preference in this screen is about making billable, all of the effort entered in Digité timesheets by the resources allocated to the various work items in the project. It is recommended that the preference about always having project creator to be the approver of the timesheets of the resources in the project is to leave the checkbox unchecked. In the second screen in Timesheet Setup Wizard,. you can select the approvers at every stage of the timesheet approval workflow. You may select Skip if you do not want to select any approvers for the timesheet workflow. Then, you need to select the date from which the timesheet entry needs to be enabled in the project. Click the Calendar to select the date. You can even select the past date. However, Digité has a preference which can control for how many past weeks timesheet entry is allowed. Suppose the preference is set to 2 weeks, then even if you select a past date in this screen which is earlier than 2 weeks from current system date, the date so selected will be accepted. However, when the resources actually start filling timesheets, they will not be able to enter time for dates earlier than 2 weeks from current system date. Digité provides the flexibility to set up specific approvers for every individual team member in the timesheet workflow stages. Select the Timesheet Workflow menu under Project Setup within your project. The list of all team members in the project is populated. Next, you need to select the team member using the checkboxes as can be seen on the screen. If you want to have same set of approvers for multiple team members, select on multiple checkboxes corresponding to those team members, and then click Batch Update. Select the approver for each stage of timesheet workflow and save. For detailed understanding of the Timesheet module, refer to the Timesheet Management Training.
Next, you need to define a product backlog based on the list of requirements. The Product Backlog Item represents all the work a team needs to complete for a release. You can create releases and iteration and then create user stories and tag them to an iteration/release. Alternatively, you can first create user stories and then create iterations and releases.
Let us start from creating a user story. From the User Story sub module, a team member can create user stories where they can enter the story estimates, and create new tasks or link existing tasks. It is important to note that the product backlogs (PBs) are estimated using Story Points or Planned Estimates—i.e. abstracted estimates of difficulty—whereas Tasks are estimated with hours. As a best practice, PBs should always be estimated using a consistent scale of Story Points. Tasks, on the other hand, should be estimated in effort logged in hours. The various features available to define a user story are: Configurable user story template: User Story eForm can be configured at the project level to meet your requirement. Rich Text Editing: You can add a Story Description using the advanced editing features such as, Formatting, Highlighting, Inserting Tables, etc. along with the most-used commands such as, copy, paste, insert images, etc. Story Hierarchy definition: You can define the story hierarchy by linking user story to the existing user story creating a parent-child relationship which will be visible in the Linked Item Section and Search-Select views. Rank and Estimate: You can rank the user story as per the priority and enter the story estimate. These fields are editable while the user story is in the progress state. Import/Export as Excel/CSV: When the user stories are created offline or you want to work on the user stories on your local system, you can import or export and work using the Excel application or just save files as CSV. HTML/ RTF Print: You can print the details of a user story in an HTML or a RTF format. Grid Add/ Edit: As per your convenience and comfort, you can add or edit multiple user stories at a time. Linked Task/Defect/Test Case Addition: To take the advantage of an integrated system, you can create new or even link Tasks, Defects, and Test Cases from the repository from the User story itself. Effort Roll-up from linked Tasks: To get instant understanding of the status of the user story, you can view the effort rolled up on all linked tasks in the user story.
When you define the user story, you need to provide following information in the Details section of the user story. Other tabs such as Previous Versions, Tasks, etc. will be displayed once the user story is saved. Name : Every User Story must have a logical name. This name should indicate what this story is about. Story Description : This is the short description of the project. The information gathered from the customer is entered in the everyday language. e.g. " Starting Application = The application begins by bringing up the last document the user was working with. " Rank : Rank is used to prioritize the user story. You need to enter a numeric value in this field. Planned Estimate : This field is used to capture User Story Points. Each story is estimated which would be rolled-up to the project estimate. Estimates give an idea how big is the User story in terms of FP, Hrs etc. whatever is the unit of measurement for the project. UOM : This field is used to define unit of measurement of User Story Points. It can be configured at the organization/Process/Project level so as to accommodate your measurement unit. Story Owner : Story owner shows list of project team members. This list will also contain names of the resources who are or were a story owner and now have been deleted or unallocated from the project. Story State : The user story state can be updated as Defined, In Progress, Completed, or Accepted. Note that story state does not depend on the workflow stage. Each story can go through its own approval workflow. Based on your process, you may configure it to meet your requirement. Story Type : The type of the story indicates whether the project is a new feature or an enhancement to the existing feature or a defect that needs attention. Release : Once a User Story is saved, based on the 'Iteration' it belongs to, the Release field is displayed. Iteration : Each user story is tagged to an iteration. Based on the relationship defined from 'User Story' section of Iteration Form, this field is shown. Fo llowing are the read-only attributes in the user story details section that are rolled up on agile forms and you may customize or create a table view based on these to quickly view the status. Task Estimates ( this value is a calculated field displayed from the hour estimates entered in the linked tasks) Traced Actual Effort ( this value is calculated based on the actual efforts logged against the tasks in the timesheet) Traced Remaining Effort (this value is calculated based on the remaining hours against the tasks) These attributes get rolled-up at ‘User Story’ eForm from Task. The user story can be routed to the Product Owner for approval. t he other sections appear based on the eForm configured at the organization/process template/project level. For example, Defect, Test Unit, Risks, etc. , you have the advantage of tracking the defects, and maintaining Test Units from the QA perspective to consider a user story to be complete in all respects and ready to be accepted.
Navigate to the user story listing page to track the product backlog. Here you can see the product backlog i.e. the list of all user stories you created.
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 highest priority and will yield the most business value, and so prioritize the PBs accordingly. In the sprint planning meeting, the Product Owner and the team negotiate which stories a team will tackle in that sprint. If any concerns are voiced or impediments seen, they are resolved by the team and the product owner.
As you can see, user stories are ranked, estimated and tagged to an iteration and in turn to project releases. As new stories arrive, each one undergoes the Product Owner’s analysis and is tagged to the Release after approval. User Story is hierarchical type of eForm and hence User Stories can be represented in a Hierarchical list. Also this User Story Hierarchy has the following behavior: - ‘Planned Estimate’ and ‘Actual/Remaining Effort’ field values would roll-up to the parent story. - Timesheet entry would get disabled for the parent story. When a User story is linked to another user story in the linked User Story section, the Story Hierarchy would be visible in the linked item section & search select views.
Once the product backlog has been defined, the release and iteration plans can be defined or these can be defined even initially and later the user stories can be tagged to an iteration/release.
To define a release and an iteration, you need to define the dates, scope, etc. as listed above.
In Agile, the first thing to look at is the releases. An agile project is broken down into set of releases. Each release will have a release date and other attributes. Digité has provided the Release eform to define releases. Navigate to the Release module as highlighted (Project Setup > Releases), which is a standard Digité eform. It. You can use release workflows to define approval workflows as well. While defining a release, you will have to enter the capacity for the release in Points, Hrs, or any other UOM and compare/ align the capacity with the user story points/estimates planned for that release. The capacity will be displayed in the Release Status report to understand whether the resources are underbooked, overbooked or correctly booked. The Release Tracking section displays the Release Cumulative chart which displays the iteration-wise cumulative estimates of the user stories. This report helps you to easily track the progress of user stories based on the change in their state as the iteration moves toward acceptance. The report is explained in detail further along with other Agile Reports .
In Agile methodology, an Iteration refers to one unit of time in which a software is developed. An Iteration typically lasts from one to four weeks. Each iteration passes through a full software development cycle: including planning, requirements analysis, design, coding, testing, and documentation. The goal of an Iteration is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities. In Digité Enterprise, Iteration eForm is available for planning 'Iterations' in a release. Name : Every Iteration must have a logical name. This name will be displayed in the iteration list of the User Story. Theme : The Theme is a rich text box where the user can enter the information or description of an iteration. Start Date : The planned start date of the iteration. End Date : The planned end date of the iteration. Release : A list of all the releases of current project is displayed. Select the Release to which the iteration has to be tagged. Iteration Goal: Each iteration would be kicked-off with certain milestones to achieve. This rich text box field provides the space to document the goal. Iteration State : The three iteration states available for selection are- Planning, Committed, Accepted.
Iteration Capacity: Define Iteration capacity (in Points, Hrs or any other UOM) and compare/ align the capacity with the user story points/estimates planned for that iteration. The above capacity is also shown in the Iteration status report to understand whether the iteration is underbooked, overbooked or matches the estimates. Also the f ollowing attributes would get rolled-up at the 'Release' & 'Iteration' forms from User Story: Story Estimates Task Estimates (linked to stories scoped in an release/iteration) Traced Actual Effort Traced Remaining Effort The Iteration Cumulative chart displayed in the Iteration Tracking section helps you to track the progress of the iteration against your planned estimates. The report is explained in detail further along with other Agile Reports . The User Story section displays the user stories if scoped for the iteration.
For each Iteration, a team member can define his/her own capacity ( in hrs) of completing the user story using effort and degree of difficulty to estimate their own work. The resource capacity for existing resources can also be copied from earlier sprints. The Product owner can use the resource capacity collectively, which is displayed in the Details section of the iteration to compare with the rolled-up task estimates. This would also help in identifying loading of the agile team members.
In the Sprint Planning Meeting , the team sits down to estimate its effort for the stories in the backlog . The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and decide which user story gets into which iteration. To add the new user story, click Link New User Story icon as highlighted and add a user story to an iteration. Existing user stories can be linked to the iteration using the Link Existing User story icon highlighted. Sometimes, you may want to move a user story from one iteration to another. To move a user story, select the user story, and click the Delete the Selected User Story Link icon. This will remove the user story link to the iteration and the user story can be allocated to any available iteration.
Typically, the product owner defines the user stories and when development team starts working on the user stories they may decide to break them down to granular tasks. To add the new task, click the Link New Task icon as highlighted and add a task to the user story. If you have already created the task in the Task module, you can link the existing task using the Link Existing Task icon as highlighted. Now that the sprint goals and tasks are defined, the team can get to work.
While the team works on their daily tasks, it is important that their efforts are captured. The tasks that are assigned to them are displayed in their Inbox and they can enter the ‘Remaining Hours’ for each task at the end of the day. At the beginning of a Task, 'Remaining hrs’ is shown equal to the 'Estimated Effort’. In the timelog, 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 1 st January as 100 hours and no timesheet was updated between 2 nd January to 5 th January. Then, it will show 'Remaining Hrs’ as 100 for all dates in between. The team member if updates the 'Remaining Hrs’ for past dates as well, Digité Enterprise will use recent 'Remaining Hrs’ entry for all tracking/metrics calculations. (Note: This functionality is governed by access rights control. The Remaining Hours entry for Tasks in a timesheet reflects the recently entered hours. For example, in the timelog for 1st January, if the remaining hours is entered as 20 and for 2nd January remaining hours is entered as 10, then in the timesheet 'Remaining Hours’ will appear as 10 hours. The daily remaining hours can be entered by double-clicking on a timelog cell. Alternatively, the team member can enter the remaining hours in the ‘Remaining Hour’ cell in the Timesheet screen which would be posted to the ‘Daily Remaining Hour’ field automatically. Also if the team member enters any actuals, the Remaining Work for the task will be reduced accordingly.
After or 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. From the Test Unit section, new test units can be created and linked to the user story, or existing test units can be linked from the Test Unit Repository. Once the tasks in the user story are completed, the developer can keep a track of defects whether all defects related to the user story were fixed or not. A tester needs to link the user story to new defects that can be created from the Defect section, or link to existing defects that were logged when executing a test event. Thus, you gain the advantage of tracking the defects, maintaining Test Units from the QA perspective to consider a user story to be complete in all respects and ready to be accepted.
It is necessary that the iteration is tracked for progress, any impediments blocking the path, and goals to be defined next. Digité provides complete information on the progress real-time through the List view of the work items, reports, charts and the traceability framework.
To track the progress of the release/iteration from the lowest level, you can track the tasks linked to user stories from the Task section in the User Story, which also displays the details such as Planned Start and Finish Dates, Actual and Planned Effort, etc.. You can create or customize the Table View to view selected columns and in the order you want. This gives an instant status of the tasks linked to a particular user story. The efforts logged in the timesheet by the team members are updated here. You can also navigate to the Tasks Module to view a Hierarchical list of tasks which also displays the Planned Start and Finish Dates, Planned and Actual Effort, Remaining Effort, etc. However, do not create tasks from the Tasks module. Use the Tasks section in the User Story to create Tasks.
It is important that as the tasks are completed, the part of the functionality/user story is tested. The Test Units created and linked to the user story can be executed through a Test Event in the Test Management module independently. You can create a Test Script for the User Story and add relevant test units to it. You can create a Test Event and add the Test Script to it and then execute the Test units. To manage the Test Execution, you can create a test plan and schedule it so that the functionality/user story is ready to be delivered without bugs.
If a test unit fails while execution, the tester can raise a defect right from the Test Execution window. A tester needs to link the user story to the defects that were logged when executing a test event from the Defect section of the user story by clicking the Link Existing Defect icon. Defects can also be created from the Defect section. Thus, t he developer can keep a track whether all defects related to the user story were fixed or not. Thus, establishing relationship between test unit, defect, and the user story, you can create a traceability map to track the progress of a user story.
To view detailed progress of Releases, Iterations, etc. Digité provides following Agile reports which are available under the ‘Report list’ module of the project for : Release/ Iteration Burndown and Burn-Up Iteration Status report Iteration burndown report Release status report Release burndown report Velocity Tracking: Iteration Velocity report Cumulative Flow: Iteration Cumulative Chart Release Cumulative Chart Team Status Report We will now study each of these reports.
A burn down chart is graphical representation of work left to do versus time. Updated every day, it gives a simple view of the sprint progress. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when the entire work will be completed. Iteration burndown chart is chart for a given iteration which shows the tendency of iteration progress with a graphical representation of the remaining work to do at the end of each passed day. To view a burndown chart, you need to select the iteration for a release. Select the project release and the iteration as highlighted. If required, you may plot the actual work data along with the remaining hours by selecting the Show Actual Work Details checkbox. On X-axis it shows data points for all 'Days’ between 'Iteration Start Date’ and 'Iteration End Date’ (including both). Data points excludes non-working days/holidays etc. If Daily remaining hours and Actual Hours is logged beyond Iteration date, those are also displayed in the Report. Remaining hours and Actual hours will be plotted till the current day. Y-axis shows the SUM of saved 'Remaining Effort’ of resources allocated to a task that are included in the user story of the Iteration. This can be Unapproved Remaining Effort. You have the option to select 'Show Cumulative Actual Work Data’ check box. If selected, the chart shows one more line for 'Cumulative Actual Work’ which is the SUM of saved 'Actual Effort’ value of tasks that are included in the user story of the Iteration. This can be Unapproved Actual Effort. All data points show values at the end of the current day and are connected with a straight line to the next data point.
A Release burndown report shows remaining work in the Release relative to the Release schedule. The value of the Release Burndown chart is derived from Iteration tagged to a particular Release. For example, if there are three Iterations i.e. Iteration1, Iteration2, Iteration3 which are tagged to Release 2, all the tasks that belong to the user stories scoped in these 3 Iterations will be considered to display the values for the Release Burndown chart. To view the chart you need to select the release. If required, you may plot the actual work data along with the remaining hours by selecting the Show Actual Work Details checkbox. • X-Axis shows the data points for all the days between ‘Release Start Date’ and the ‘Release End Date’ (including both). ‘Release start date is the start date of the earliest Iteration tagged to a Release’. ‘Release End date’ is the Release Due date. • ‘ Release end date is the max {end date of all the Iteration tagged to a release}. Data points will exclude non-working days –weekends/holidays etc. Day 0 is the day prior to the planned start date of the release. • Y-axis shows SUM of ‘Remaining Effort’ field of tasks that are included in the user story of the iteration, tagged to the Release. • A straight line connecting Point A (X=0 and Y= Remaining Work on Planned Start Day) AND Point B (X= Planned End Day and Y=0), is also shown in the chart. • You have an option to select ‘Show Cumulative Actual Work Data’ checkbox. If the checkbox is selected, the chart shows one more line for ‘Cumulative Actual Work’, which is a SUM of ‘Actual Effort’ field of task that are included in the user story of the Iterations, tagged to a Release. • All the above figures show values at end of current day. For example – ‘Remaining Work’ data point for Tuesday shows value of ‘Remaining Work’ as calculated on Tuesday midnight. • All data points are connected with a straight line to the next data point.
Velocity is a rough estimate for the amount of work that a team can accomplish in a given sprint. It is calculated by simply adding up all the completed story points. It becomes a valuable metric over time as teams complete multiple sprints and have the opportunity to establish a consistent velocity. The Iteration Velocity Report helps the Product Owner to look to the team’s established velocity to determine how much work it can tackle in the next sprint. Iteration Velocity Report displays the functions delivered or the story points completed in each sprint/iteration in a graphical format. On X-axis it shows data points for all the Iterations in the selected release and the Y-axis shows Planned Estimate Values. Value of ’Functions Delivered’ for each iteration is SUM of ’Planned Estimate’ of all User Stories traced with each Iteration.
The Release Cumulative chart displays the iteration-wise cumulative estimates of the user stories. This report helps you to easily track the progress of user stories based on the change in their state as the iteration moves toward acceptance. Y Axis : Planned estimates is displayed here incremental of the sum of story estimates in the iteration. X Axis : The iterations planned in the release . Through the progress of the user story states you can find how much work has moved from one state to another, as well as note if there's any additional scope added. For example, if the planned estimate rises from 40 to 80, it translates to addition in the scope of work in the iteration. If suddenly, larger portion of estimate increases from accepted to completed story state, it may indicate that the customer has rejected the work. To view the Release Cumulative chart for a release, s elect the release from the list of release s in your project and the iteration from the Iteration list, and then click Go. The Release Cumulative Chart is displayed for the selected iteration in a release . You can also view the chart in the Release Tracking section of a Release from Project Setup>> Release s.
The Iteration Cumulative chart helps you to track the progress of the iteration against your planned estimates. It provides the cumulative estimates of story states to understand how the iteration has progressed through the iteration start date and the end date. You can determine any bottlenecks and alter your plans to resolve them. Y Axis : Planned estimates is displayed here incremental of the sum of story estimates in the iteration. X Axis : The dates are displayed from the iteration start date through the end date. Through the progress of the user story states, you can find how much work has moved from one state to another, as well as note if there's any additional scope added. For example, if the planned estimate rises from 40 to 80 the day before, it translates to addition in the scope of work in the iteration. If suddenly, larger portion of estimate increases from accepted to completed story state, it may indicate that the customer has rejected the work. To view the Iteration Cumulative chart from the release list, select the release and the iteration, and then click Go. The Iteration Cumulative Chart is displayed for the selected iteration. You can also view the Iteration Cumulative chart the Iteration Tracking section of the selected iteration.
It is important that the team and the product owner regularly monitors the team’s progress. The Team Status report shows the status of tasks completed by the project team members and also highlights whether the planned effort is greater or lower than the capacity, or matches the individual resource capacity. You can filter the report by resource group further to view whether a group member is overbooked, under-booked, or has been assigned with tasks with estimates matching his availability or planned capacity for the iteration. Resource Name : Name of the team member in the resource group. User Story:- The name of the user story for which the task has been assigned to the user. Task Name:- The name of the task to which the resource is assigned. Status :- The status of the Task( Open/Closed/Past Due) for the 'Tasks’ and the state of the story as set in the 'Story State’ attribute of the User Story instance. Release :- Name of release to which the user story belongs. Iteration:- Name of Iteration to which the user story belongs. Story Estimates :- 'Planned Estimates' for the user story. Capacity : The total capacity of the resource in the iteration. If 'All’ value has been selected in the 'Iteration drop-down, this attribute then shows the sum of resource’s capacity across all the Iterations. The capacity for the resource (in hours) is shown, as entered in the 'Resource Capacity’ section of an Iteration. The capacity thus shown can be compared with the sum of 'Planned Effort’ of all the tasks assigned to the resource to understand if the resource is overbooked, under-booked, or equals the estimates. This field is highlighted in the report using Green, Amber or Red color to indicator Under-booking, Equal-booking or Over-booking of a resource. Planned Effort :- The sum of 'Planned Effort' for the tasks on which the resource has been assigned. Against User Stories, the same field shows the sum of 'Planned Effort’ of all the tasks linked to the user story. Actual Effort :- The sum of 'Actual Effort' for the tasks on which the resource has been assigned. Against User Stories, the same field shows the sum of Planned Effort’ of all the tasks linked to the user story. Remaining Effort: - The sum of 'Remaining Effort' for the tasks on which the resource has been assigned. Against User Stories, the same field shows the sum of 'Planned Effort’ of all the tasks linked to the user story. % Progress: - Completion of the tasks/User Story in percentage.
Iteration Status Report shows the details of various iterations in the project. On further drill-down, the report shows details of a selected Iteration. The following is a typical screenshot of a Iteration Status Report. To generate a Iteration Status Report, select the release from the list, and then click Go. The Report displays two sections—Iteration Tracking Report and Iteration Details. The report displays all the iterations tagged to the selected release. Iteration Name – Shows the Iteration name listing all ‘Iterations’ associated with the selected ‘Release’. Start date – Start Date of the earliest Iteration tagged to a release. End Date – End Date of the latest Iteration. No of User Stories – Is a count of ‘User Stories’ traced with all the iteration tagged to the release. Capacity - The capacity of the iteration as entered in the capacity field of the iteration. This is used to compare the planned estimate of the user story scoped in the iteration. This helps to understand if the iteration is overbooked, under-booked, or equals the estimates and is highlighted in the report using Green, Amber, or Red color. Planned Estimate –Sum of all the Planned Estimates of an iteration tagged to the Release. Estimated Work – SUM of 'Estimated Effort’ of resources allocated to tasks that are included in the user story of the Iteration. Actual Work - SUM of saved 'Actual Effort’ of resources allocated to tasks that are included in the user story of the Iteration. This can be Unapproved Actual Effort. Remaining Work – SUM of 'Remaining Effort’ of resources allocated to tasks that are included in the user story of the Iteration. This can be Unapproved Remaining Effort. % Progress – it is calculated using % Progress = (Estimated Work - Remaining Work)/ Estimated Work *100 Note: Even the 'Unapproved' or 'Saved' timesheet is considered in this report. You can click the Iteration Name link to view its details as highlighted. The report displays details of User Stories associated with selected Iteration and the Tasks linked to each user story. Item Type – User Story and Tasks associated to the selected Iteration. Item Name – Name of the user story/task. Owner – The Owner from the User Story and Task Allocations/Assignments for Tasks. If there are more than one resources assigned to a user story or a task the individual details for each appear below. Item State – For User story, report displays the ‘Story State’ of the User Story. For Task, the report displays the ‘Overall Status’ (Open or close) of the task. Planned Estimate – For User stories displays value of ‘Planned Estimate’ from the user story. For Task it should display “—NA—“. Estimated Work – User Story, Sum of 'Estimated Effort’ of resources allocated to tasks that are included in the selected user story. For Task, displays ‘Estimated Effort’ of each Task. Actual Work – For User Story, Sum of 'Actual Effort’ value of tasks that are included in the selected user story. For Task, displays ‘Actual Effort’ of each task. Remaining Work – For user story, Sum of 'Remaining Effort’ value of tasks that are included in the selected user story. For Task, displays the ‘Remaining Effort’ of each task.
Release Status Report is to view details of various Releases in the project drilled-down to show the status of Iterations further to the user story and task level. To view the report, select the release and the iteration tagged to the selected release. Item Name – Shows the Release Name and list of all ‘Iterations’ associated with selected ‘Release’. Start date – Start Date of the earliest Iteration tagged to a release. End Date – End Date of the latest Iteration. No of User Stories –Count of ‘User Stories’ traced with all the iterations tagged to the release. Capacity : The total capacity of the release as entered in the capacity field of the release. This is used to compare the Planned Estimates of the user stories scoped in the iterations that are being executed in the Release. This helps to understand if the release is overbooked, under-booked, or equals the estimates and is highlighted in the report using Green, Amber or Red color. Planned Estimate –Sum of all the Planned Estimates of an Iteration tagged to the Release. Estimated Work –Sum of ‘Estimated Effort’ value of an Iteration tagged to the Release. Actual Work - Sum of ‘Actual Effort’ field of an Iteration tagged to the Release. Remaining Work –Sum of ‘Remaining Effort’ field of Iteration tagged to the Release. % Progress – it is calculated using % Progress = (Estimated Work (of Release) - Remaining Work (of Release)/ Estimated Work (of Release) *100 You can click the Iteration Name link to view its details as highlighted. The report displays details of User Stories associated with selected Iteration and the Tasks linked to each user story. Item Type – User Story and Tasks associated to the selected Iteration. Item Name – Name of the user story/task. Owner – The Owner from User Story and Task Allocations/Assignments for Tasks. If there are more than one resources assigned to a user story or a task the individual details for each appear below. Item State – The 'Story State’ from User Story and 'Overall Status’ for Task. Planned Estimate – The Planned Estimate value from User Story, and '--NA--' for Tasks. Estimated Work – User Story, Sum of 'Estimated Effort’ of resources allocated to tasks that are included in the selected user story. For Task, displays the ‘Estimated Effort’ of each Task. Actual Work – For User Story, Sum of 'Actual Effort’ value of tasks that are included in the selected user story. For Task, displays the ‘Actual Effort’ of each task. Remaining Work – For user story, Sum of 'Remaining Effort’ value of tasks that are included in the selected user story. For Task, displays the ‘Remaining Effort’ of each task.
The Scrum methodology emphasizes communication and collaboration amongst the team members. The Meetings sub module in the Collaboration module provides space as a Meeting organizer for the team to manage their daily stand-up, sprint planning, review and retrospective meetings. The team members can schedule, invite, approve, add minutes, note and track the action items, and even trace with the other work items. The meetings that you can organize for a Scrum are described below: In Scrum, every iteration begins with the sprint planning meeting. At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint. Time-boxed to four hours, this meeting is a conversation between the Product Owner and the team. That is, it’s up to the Product Owner to decide which stories are of the highest priority to the release and which will generate the highest value. The heart of the Scrum process is the daily standup meeting, also known as the daily Scrum. No other meeting captures Scrum’s emphasis on communication and transparency quite like the standup. This meeting helps ensure that the entire development team is always on the same page. It allows the team to track sprint commitments and work. In Scrum, when the sprint ends, it’s time for the team to present its work to the Product Owner . This is known as the sprint review meeting. At this time, the Product Owner goes through the sprint backlog and asks the team to present its work. The Product Owner checks the work against the acceptance criteria to determine if the work is satisfactory or not. After the sprint review meeting, the team and the ScrumMaster get together for the retrospective meeting. During this meeting, the team considers three things: what went well, what didn’t, and what improvements could be made in the next sprint. Digité also provides a shared space for the team members to share information and collaborate informally. Initiate topics to be discussed, post views, and share and update your knowledge on any topic. Maintain wiki pages for topics and discussions using the
The Meeting Minutes Workflow is brief to facilitate the rapid publishing of the information. Link the Minutes to other items as necessary. Add Action Item by clicking this button Creating a new item would lead to that Module The application Will return to this stage after that step. Route the meeting and notification will be delivered in the inbox of the attendees. To add Meeting Minutes, click Add Meeting Minutes icon. Then populate the mandatory data fields and optional fields as appropriate. To link the minutes to other items, from the Traceability section. Route the Meeting to others using the Workflow feature.
Wikis empower groups by providing capabilities to manage websites in collaboration as knowledge management systems, in corporate intranets, or for taking down personal notes. In Digité, each project workspace can have a wiki , containing multiple pages where all the team members can collaborate and produce various project artifacts or exchange relevant project information. All the pages in the wiki are editable by the team members who have access to the wiki module in Digité. The wiki page can be automatically edited in the WYSIWYG mode. The other edition modes available is the Wiki Edition Mode using which you can add text using a simple Wiki Syntax. For more understanding on the Wiki module, refer to our Collaboration Modules training.
Unlike rest of Digité Enterprise where configurability is available for Organizations to model their own solution, Digité’s Agile solution is thoroughly researched and pre-configured to offer Agile features based on Agile manifesto. So it’s recommended to go through these’ Dos & Don'ts’ related to the usage of Agile Project Management with Digité Enterprise. 1. Specify Iteration ‘Start Date’ and ‘End Date’: These dates form the basis for ‘Iteration/Release Status Report’ and ‘Iteration/Release Burndown Report’ 2. Specify ‘Planned Estimate’ for each User Story: These estimates should be captured to view ‘Iteration Velocity Report’ 3. Save Timesheet after entering ‘Daily Remaining Hours’ for tasks: Agile manifesto believes in ‘Responding to change over following a plan’. Hence by design the ‘Iteration/Release Status Report’ and ‘Iteration/Release Burndown Report’ are based on ‘Saved’ timesheet data and ignore timesheet approval cycle. i.e. Both the ‘Iteration/Release Status Report’ and ‘Iteration/Release Burndown Chart’ will show the latest saved time for both ‘Actual Hours’ and ‘Remaining Hours’. 4. Regularly fill ‘Daily Remaining Hours’ for tasks: To log in ‘Remaining Hours’ for task, double-click on the cell of the timesheet to fill in ‘Daily Remaining hours’. If there is no time entered for daily remaining hours for any day, then 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 last date filled in remaining hrs. 5. Only link sub tasks to User Story: Subtasks/milestone task can be linked to the User story. But Summary task can not be linked to the User Story. Also, if a task is linked to any User Story in project, then the same task can’t be linked to any other User Story. To summarize, the ideal way is to take a User Story and break it down into tasks. And not create tasks upfront and link them to user stories! 6. Avoid confusion in Burndown chart by planning non-overlapping iterations in a release: Value of the Release Burndown chart is derived from Iteration tagged to a particular release. e.g. Iteration Alpha, Iteration Beta and Iteration Gamma is tagged to Release 2, then all the tasks that belong to all the user stories of these three Iterations will be considered to derive the values for the Release Burndown chart (i.e. Release field on user story or task has no significance for any Agile Reports). 7. Do not compare or find relation between the Iteration dates and Release date (of Release Form), as there is no relation between the Iteration date and Release Date. Release ‘Start date’ for calculation will be earliest date of all the associated Iteration ‘Start Date’. Release ‘End date’ for calculation will be latest date of all the associated Iteration ‘End Date’.
1. Task Dates beyond Iteration dates: Tasks included in the Iteration should be in scheduled the between Iteration start and Iteration End date. Although there is no restriction of only adding task between the Iteration start date and Iteration End date. Burn down chart will only show data starting from iteration day. i.e. even if one has certain task included in the Iteration that starts prior to Iteration start date, Iteration Burndown chart will show data as is from Iteration start day. 2. Don’t move User Story (with completed tasks) to other Iteration: If there is any User story in a particular Iteration with any task completed/in-progress, when user removes this user story from one Iteration and moves it to another Iteration, all the time log entered for the tasks belonging to former iteration will be shown in the burndown chart and Iteration Status Report of latter Iteration (with the constraint mentioned in point 1). 3. Do not compare Remaining hrs for Agile Projects and Other Projects: For Agile Projects - it’s the latest Daily Remaining Hrs filled in Timesheet. For other projects, Remaining Hrs is alwaysthe difference between ‘Estimated Effort – Actual Effort’. 4. Do not change the Traceability setting among Iteration, User Story and task. These relationships are needed for the overall agile functionality to work. With random changes to the traceability, users will be left with incomprehensible reports/burndown chart. 5. Do not compare ‘Actual Hours’ in ‘Iteration/Release Status Report’ or ‘Iteration/Release Burndown Report’ with ‘Actual Hours’ on Task Form. A discrepancy could exist due to the fact that reports show ‘Saved’ timesheet data, whereas Task details are updated only after timesheet is approved and closed. 6. Do not compare ‘Remaining Hours’ in ‘Iteration/Release Status Report’ or ‘Iteration/Release Burndown Report’ with ‘Remaining Hours’ on Task Form. A discrepancy could exists due to the fact that reports show ‘Saved’ timesheet data, whereas Task details are updated only after timesheet is approved and closed. 7. Do not close/delete any task that is not completed in the current iteration: There are two ways to manage it – a. Move Entire Task to Next Iteration: Go to the user story where the task is currently traced and disassociate the task with current user story. Now go to the new user story which is a part of next iteration and search & trace this task to new user story. A caution here- By moving task from one iteration to other iteration this way, entire effort of task will move from previous iteration to new iteration. b. Split incomplete task into multiple tasks: Any incomplete task should be split into multiple tasks (manually). Original Task associated with earlier iteration should be marked complete. Split (new) task should be traced to next iteration. Following this approach will make sure any effort logged associated with earlier iteration is not lost from that iteration. 8. Do not convert a normal task in a user story as a summary task . Changing a normal task to a summary task will create discrepancy in the Burndown chart.
With this, you have come to the end of the Agile Project Management training. To summarize, you have learned the concept of Agile in detail. You should have understood how agile project management works in Digité. You have been walked through various features available in Digité for managing Agile projects. You have also seen the reports and charts related to Agile module. Now you should be able to use the agile methodology using the Digité application.
You may proceed with the hands-on on the topics covered in this training session. Log into the application & get familiar with the features covered in various training topics. Identify some real-life scenario from one of your projects where you can apply the agile methodology. Try to model that scenario using Digité.
Thank you for attending the training session. Have a good day.
