Managing Agile Projects in TestTrack GUIDE

Transcription

1 Managing Agile Projects in TestTrack GUIDE

2 Table of Contents Introduction...1 Automatic Traceability...2 Setting Up TestTrack for Agile...6 Plan Your Folder Structure Building Your Product Backlog Planning Releases Planning Sprints Keeping Sprints on Track Managing New Issues and the Backlog Completing Sprints and Releases Completing Releases You re Now Ready to Manage Agile Projects with TestTrack... 34

3 Introduction Whether you re currently using an agile or hybrid method or are transitioning from a more traditional development process, you can use TestTrack to manage your agile projects. From capturing user stories to reviewing effort at the end of releases and sprints, TestTrack helps you track project status every step of the way. While some product development solutions force you into a process, TestTrack can support your agile methodology without requiring your team to change how they work. And, if some teams in your organization use agile or hybrid methods and others use more traditional processes, TestTrack enables you to manage those efforts in parallel. The examples in this guide focus on Scrum, but the general concepts can be applied to most agile or hybrid methods. Managing Agile Projects in TestTrack seapine.com 1

4 Automated traceability matrices make it easy to quickly perform coverage analysis. Automatic Traceability Let s begin with traceability. Because agile generates less documentation, it can be challenging to maintain the required records and traceability matrices needed to satisfy auditors. This is especially true if you try to produce this documentation at the end of the development cycle. The time and effort required to manually create a trace matrix after the work is done can take days or even weeks, effectively stalling productivity during that time. This type of manual approach is also prone to errors and missing data. The most effective way to manage traceability in an agile or hybrid process is to create the trace matrix at the beginning of the project and maintain it throughout. This can still be a difficult and time-consuming method when done manually, however. TestTrack can automatically generate the required documentation and maintain traceability throughout the product development lifecycle. With TestTrack, you can focus on building high-quality software without having to deal with traceability documentation. TestTrack automatically provides traceability as it is needed, making the traceability matrix into a useful tool instead of just a checklist item at the end of a project. Requirements and Risk Management TestTrack provides agile teams with instant traceability of changing requirements, risk artifacts, and other associated work items. With TestTrack, you can automatically track requirement changes and requirement-to-user story evolution, and calculate risk values. You can also generate traceability matrices to record risk control measures, requirements, architecture and design elements, and verification and validation. Figure 1: TestTrack automatically generates traceability matrices like the one shown above. Managing Agile Projects in TestTrack seapine.com 2

5 Automated traceability matrices make it easy to quickly perform coverage analysis by viewing the relationships between requirements and tests. For example, you can make sure at least one test case has been generated for each approved requirement in a project. To facilitate change tracking and versioning, TestTrack can take snapshots that capture the state of requirements documents at a specific point in time. Use snapshots to compare requirement document versions and view differences between them, typically in conjunction with project milestones, such as when the first draft of a requirement document is complete. Figure 2: Snapshots capture the state of requirements documents at a specific point to facilitate tracking changes. Requirement linking helps establish relationships between items and propogate changes to related items when requirements change. With TestTrack, you can link requirements to other items, including: User stories Risk assessments Feature requests Issues and defects Change requests Test cases and results Suspect item flagging shows the linked items to review when a related item changes. The complex relationship between requirements and other development artifacts means if an item changes, related items need to be reviewed to determine if they should also change. Impact analysis reports make it easy to view items related to requirements and understand the impact of a requirement change before it s made. You can perform an impact analysis to view the related items, assess the risk of making changes, and identify the items that need to be reviewed based on the changes. Those items can then be flagged as suspect to streamline and automate change reviews. Suspect item flagging allows teams to determine which linked items (i.e., requirements, test cases, issues, change requests, etc.) need to be reviewed when a related item changes. Managing Agile Projects in TestTrack seapine.com 3

6 Figure 3: TestTrack allows suspect items to be flagged to streamline and automate change reviews. TestTrack s requirement review features facilitate the review process by allowing review participants to add review notes that appear inline in requirements documents. s relevant to a requirement are also tracked with the requirement to further facilitate communication and collaboration. TestTrack automatically maintains and reports on the links between requirements and tests. Test Planning While testing is critical to ensuring requirements are implemented correctly, it s just as important to prove to auditors that you ran the tests that verify and validate each requirement. TestTrack is a central repository for your test cases and test results, automatically maintaining and reporting on the links between requirements and tests, along with the reporting necessary for comprehensive historical proof. Teams developing safety-critical products require strong objective evidence, which TestTrack can easily enforce and provide. Managing Agile Projects in TestTrack seapine.com 4

7 Issue Tracking Although agile can help reduce the amount of issues, it won t completely eliminate them. You will still need a way to track issues. TestTrack is flexible enough to support the agile process, as well as provide traceability from issues back to tests and requirements. Task Tracking Agile projects have thousands of work items to create, assign, and track. Most versions of agile call for the use of a task board or kanban board, but these can become cumbersome for larger, complex projects or when the team is not working together in a single location. TestTrack can help efficiently manage and report on tasks, user stories, story points, time tracking, and other agile work items. All stakeholders are regularly updated by automatically generated burn down, burn up, and velocity charts and other reports. Managing Agile Projects in TestTrack seapine.com 5

8 Setting Up TestTrack for Agile Now let s take a look at how to configure TestTrack for agile. Folders and reports are the basis for managing your agile projects. You ll configure folders and tracking in your initial project setup, and generate reports throughout the project to review status. Folders are used to organize backlogs and are the key to planning and managing releases and sprints. No matter what requirements technique you use (e.g., user stories or use cases), users can easily add, modify, and delete requirements directly from the product backlog. Customizable fields also allow teams to update tasks with minimal clicks, ensuring they spend less time updating statuses and more time developing. TestTrack makes it easy to create user stories, and assign acceptance criteria and story points to them. As the team completes stories or as stories are added and removed, burn down and burn up charts are updated automatically. Agile reports provide the data you need for release and sprint planning, daily Scrums, and retrospectives. If you re creating a new project to support your agile practice, use the Scrum sample project as a template. If you re reconfiguring an existing project, use the Scrum sample project as a reference. Determine the Agile Artifacts You Want to Track Before you configure TestTrack, you ll need to determine the agile artifacts you want to track. Create a list of the artifacts to refer to as you go along. Managing Agile Projects in TestTrack seapine.com 6

9 The following contains some common agile artifacts and their TestTrack equivalent: AGILE ARTIFACT Release Sprint Theme Backlog Story map User story Bug Epic Task Test case Feature request Story points Acceptance criteria Impediment Detailed estimates Actual and remaining hours TEST TRACK EQUIVALENT Folder Folder Folder Folder or requirement document Requirement document Folder, issue (simple stories), or requirement Issue Folder or requirement document Issue or requirement document Test case Issue Custom field or workflow event Custom field or workflow event Workflow event Workflow event Workflow event Before configuring TestTrack, determine the agile artifacts you want to track. Rename TestTrack Items to Match Your Terminology Now that you ve determined the artifacts you want to track, rename the TestTrack items to match your terminology. For example, if you track defects, you may want to rename Issues to Defects. Managing Agile Projects in TestTrack seapine.com 7

10 The following list contains the recommended item types for managing Scrum projects: Bugs Renamed from Issues. Used for work items and issues. Test cases Test runs The folder structure you use depends on how you want to organize projects. Requirements Used for stories, epics, and detailed tasks related to stories. Epics Renamed from Requirement Documents. Used to create dependencies between related stories and organize tasks for each story. Create Folder Types to Categorize Data Folder types provide a way to tag a group of folders used for similar purposes, which is especially useful for reporting. Types control the availability of additional folder information and the appearance of folders. Most importantly, folder types are where you enable release planning fields. When you create a folder, you assign a folder type to it. Figure 4: Create folder types to categorize the agile artifacts you track. To determine the folder types you need to create, look at the list of agile artifacts you created. Think about how you want to report on information for each of those artifacts to decide on the folder types to create. For example, you will likely use the Product, Release, Sprint, and Backlog folder types because you ll want to generate reports for items in those folders. Managing Agile Projects in TestTrack seapine.com 8

11 The following table contains some commonly used folder types for agile projects. ICON FOLDER TYPE ENABLED FOLDER OPTIONS Folder None Product Release Sprint Backlog Details and Web View Release Planning, Details, and Web View Release Planning, Details, and Web View Details and Web View Tests Details and Web View User story Details The folders you create to represent releases should always use a Release folder type with release planning fields enabled so your team can enter release duration and resource availability information, automatically calculate the available man hours for the release, and track the schedule throughout the project. Use the Sprint folder type for sprint folders for the same reasons. Managing Agile Projects in TestTrack seapine.com 9

12 To capture story points, add a Story Points custom field to items. Plan Your Folder Structure Take the time to plan and document the folder structure you want to use. It s important to create a structure that reflects how your products and projects are grouped and organized to ensure useful data is included in reports. The folder structure you use depends on how you want to organize projects, but you will likely use either a product- or release-based structure. You may want to wait to create the folders when it s time for release and sprint planning because that s when you know how many sprints are included in the release and the exact folders to create. Product-based Folder Structure If you have multiple products that are released at different times and you need to manage them separately, use a structure based on product. In the following example, products are at the top of the hierarchy. Each product folder includes a product backlog folder and release folders, and each release folder includes sprint folders. You can also create folders for tests in this structure. Figure 5: Use a product-based folder structure to manage multiple products with different release schedules. Release-based Folder Structure If you have one product or multiple products that are released at the same time, use a structure based on releases. In the following example, releases are at the top of the hierarchy. Each release folder includes product folders, which contain a product backlog folder and folders for each sprint. The sprint folders are named to represent the product, release and sprint. For example, folder A_3.5_1 indicates that the folder contains items for Product A, release 3.5, and sprint 1. This naming convention makes it easy to identify the sprint in reports and other areas. Managing Agile Projects in TestTrack seapine.com 10

13 Figure 6: Use a release-based folder structure to manage releases of multiple products at the same time. Again, your folder structure should be based on how you organize projects, but these are some common approaches. You also need folders for your product backlog, but we ll discuss that later. Reconfigure Your Workflows to Match Your Process When you adopt agile, your development process changes and those changes affect your TestTrack workflows. Review the workflows for each item type and decide if you need to add or remove states, add or remove events, modify settings on existing states and events, modify transitions, or change assignment rule options. The workflows in the Scrum sample project can help you determine some of the changes you may need to make to your workflows. Configure Story Points for High-Level Estimating Story points are a popular way to capture estimates on items in the product backlog. Because it s virtually impossible to know exactly how many hours it will take to develop a feature, story points allow teams to estimate based on relative sizing instead of guessing a number (in hours) that they know will be inaccurate, yet they may be inappropriately held accountable to. To capture story points, add a Story Points custom field to items. Managing Agile Projects in TestTrack seapine.com 11

14 TestTrack automatically calculates the total time spent on individual items and across all item types. Ideally, any team member should be able to edit story point values. However, you can limit story point field access to just the team or open it up to other stakeholders. Again, TestTrack gives you full control over who can access fields. After you create the field, you need to map the Story Points field in the Time Tracking project options for the item type. Figure 7: Create a Story Points custom field. Figure 8: Use the Story Points field to capture high-level estimates. Managing Agile Projects in TestTrack seapine.com 12

15 Figure 9: Select the field to use to calculate story points in the Time Tracking project options. You can enter another name for this field if your organization uses a different method for estimating. Regardless of the name, you ll want to use an integer field for tracking high-level estimates during sprint planning. Configure Time Tracking to Capture Estimates and Work Performed The flexibility of time tracking in TestTrack gives your team the ability to track what is important to them. Estimated, actual, and remaining hours can be tracked at the depth you prefer, from project to task level. When users enter an event, such as entering work on a task, they can enter time spent on the item and the time remaining to complete it. As items move through the workflow and users continue to enter time tracking values, TestTrack automatically calculates the total time spent on individual items and across all item types. You can choose the field values used to total estimated, actual, and remaining hours for each item type. Managing Agile Projects in TestTrack seapine.com 13

16 Figure 10: Capture time tracking information in workflow event dialogs. If you already use time tracking, evaluate the existing configuration and make adjustments based on other project configuration changes, such as adding workflow events. If you re just getting started with time tracking, you need to configure it to support your agile practice. Add New Workflow Events to Capture Time Incrementally You may need to add new workflow events to capture time tracking information. For example, agile projects typically have an Enter Work event, which is used to enter actual and remaining time incrementally as users work on items. This is an informational event that does not change an item s state or the current assignment. After completing the initial setup work, the time spent administering the project will be minimal. You can also add time tracking fields to existing workflow events. To keep your workflow simple, only create new events if they are needed. Add Time Tracking Fields to Events Review your workflows and decide where you need users to report time spent on activities and if you need to capture estimated, actual, or remaining time or any combination of these values. Next, add time tracking fields to events. You can use the built-in time tracking field or a custom field depending on how you want to calculate values and if an event can be entered multiple times on an item. Use the built-in time tracking field if items can have multiple instances of the same event. This allows you to choose how to calculate the total hours. Managing Agile Projects in TestTrack seapine.com 14

17 Use a custom field to capture more than one time tracking value per event, and always use the value entered in the last instance of the event to calculate total hours. If items can only have one instance of an event, you can use either type of time tracking field. You can also use a combination of built-in and custom fields in one event dialog box to capture multiple time tracking values for an activity. For example, you may want to use the built-in field to capture actual time and a custom field to capture remaining time. To add the built-in time tracking field to an event, select the Display the time tracking field: option on the Details tab in the Edit Event dialog box. The Sum of all hours from events of this type option is selected by default. If you want to use the most recent value entered on an item, select the hours from last entered event of this type option. Figure 11: Use the built-in time tracking field for events that can be entered more than once for an item. To add a custom field to an event dialog box, click the Custom tab in the Edit Event dialog box, click Custom Fields, and then click Add. Select Integer or Decimal Number as the Format. Managing Agile Projects in TestTrack seapine.com 15

18 Figure 12: Use a custom field to capture more than one time tracking value per event. Make the built-in or custom time tracking field required if you always need to capture a specific time tracking value for an event. Select the Fields to Include in Totals After you configure time tracking event fields, you need to map the fields you configured to the time tracking values you want to associate them with. You map fields for each item type in the Time Tracking Project Options. Don t forget to monitor new items others add to the project to make sure they are in the right backlog folder. The available fields for actual, estimated, and remaining hours include built-in time tracking fields and integer and decimal number event custom fields. You can use one field or a combination of fields to calculate each value. If you select multiple fields, with the exception of story points, the sum of each field value is used as the total. You can only map a single custom field to TestTrack s built-in story point field. Figure 13: Map the time tracking fields you configured to the appropriate categories in the project options. Managing Agile Projects in TestTrack seapine.com 16

19 Make Other Configuration Changes to Support Your Process You ll probably need to make additional configuration changes to support your agile method and processes. The following are a few areas that you should evaluate and change as needed. Review the Scrum sample project for examples of how these areas and others could be configured. Fields You may need to rename existing field labels, add or modify list menu values, or add custom fields. For example, you may want to add custom fields to track personas and requirement priorities. Security groups You may need to create security groups or modify existing ones based on the team and roles involved. Filters You may need to add or modify filters used in list windows, reports, and automation rules. Automation rules You may need to add or modify notifications, triggers, and escalation rules to keep items moving throughout your process. You may also need to modify templates to make sure s include essential information based on when they are used. You re Now Ready to Start Using Your Agile Project After the initial configuration is complete, you are ready to start working in your project. You will probably need to make adjustments to the configuration during the first release, but after completing the initial setup work, the time spent administering the project will be minimal. Managing Agile Projects in TestTrack seapine.com 17

20 Building Your Product Backlog Before you start your first release, you need to build your product backlog. The backlog is used to organize and prioritize customer requests based on feedback and business value. It typically contains bugs, technical debt, and feature requests. If you ve already planned future releases, you may want to create folders for those releases now. An up-to-date backlog keeps projects moving because teams do not have to wait between each development interval while decisions are made about what to work on next. An organized, current backlog also prevents teams from working on features that are no longer the best value for the business. The Product Owner typically manages the backlog. Figure 14: Use a folder for your product backlog to prioritize items. Review and Add Items to the Backlog If you have an existing backlog, you need to move items to the appropriate backlog folders and prioritize them. This can be a big undertaking if you have a large backlog. You can move all items into the backlog before starting the project, but it is better to move existing, high-priority items into the backlog folder after you review and prioritize them. After items are moved to folders, add story points to items to indicate the relative size of the effort required for implementation and testing. The story points may change over time. When it s time to select items to include in the sprint, the team can evaluate the assigned story points and make any adjustments. Managing Agile Projects in TestTrack seapine.com 18

21 Add New Items to the Backlog Folder If you don t have a backlog or you ve already organized and prioritized your backlog, create new items, such as stories, directly in the appropriate backlog folder. Don t forget to monitor new items that other team members add to the project to make sure they are in the appropriate backlog folder. Figure 15: Add new items to the appropriate backlog folder. Prioritize the Backlog with Ranking TestTrack s ranking feature allows you to easily prioritize items in a folder. For example, you can indicate the priority of items to complete in a sprint. Figure 16: Use ranking to prioritize items in your backlog. Managing Agile Projects in TestTrack seapine.com 19

22 Each story needs to be small enough to complete in one sprint. Planning Releases You re now ready to hold a release planning session with your team. The primary goals of this session are to identify the strategic goals for the release and establish potential release dates based on the sprint length and the number of sprints in each release. In TestTrack, you ll create folders for the release and sprints, enter information in the release planning fields for the release folder, and add the release goals to the release folder. The Product Owner is typically responsible for these tasks. Create Release and Sprint Folders Create a folder for the release using the Release folder type, and folders for each sprint using the Sprint folder type. If you use a release-based folder structure, the release folder may simply serve as a container for the sprint folders and not contain any items. If you use a product-based folder structure, you need to add a product folder at the top of the hierarchy. This is an easy task if you have already planned your folder structure as recommended. If you have already planned future releases, you may also want to create folders for those releases now. Figure 17: Create release and sprint folders to start the release planning process. Create User Story Folders to Rollup Task Time Create a folder that includes all the tasks for a specific user story. You can insert column footers to display the total value of numeric columns. This is useful as a quick reference for release tracking information, such as viewing estimated and actual hours for a user story. Add the user story to the folder for reference. Figure 18: Create user story folders that include all tasks for a story. Managing Agile Projects in TestTrack seapine.com 20

23 Set Duration and Resource Availability in the Release Folder Enter the release planning information, including start and end dates, holidays and other non-working dates, working hours in the day, users available to work on the release, and vacation and sick time for the release folder. The number of available working days, working hours, and man hours are automatically calculated after you enter the planning information. If the information changes during the release, you can update it anytime. Figure 19: Enter release planning information on the release folder to calculate available man hours. Release planning information is displayed on the Release Planning tab when the release folder is selected in the Folders list window. This tab is automatically updated, and displays the current remaining days and available man hours. Figure 20: Click on the Release Planning tab to see updated progress information. Managing Agile Projects in TestTrack seapine.com 21

24 Add the Release Goals to the Release Folder During the release planning session, the team will agree on functional and business goals for the release. These goals are typically based on customer feedback and the value to your business. The Scrum Master plays an integral role in keeping things moving throughout a sprint. To make the goals visible to team members throughout the project and capture the goals for historical purposes, edit the release folder to add the goals to the Details tab. You can also insert report hyperlinks so team members can easily check on the status of the project. Managing Agile Projects in TestTrack seapine.com 22

25 Planning Sprints The first day of a sprint begins with a sprint planning session. The goal of this session is to make sure the team has a clear vision of what will be delivered at the end of the sprint. During this session, your team will likely determine the stories to complete for the sprint, decide on the target story points to accomplish, add specific tasks to develop stories, and provide estimates in hours for those tasks. Enter Release Planning Information for the Sprint Folder Just as you did for the release folder, add information to the release planning fields for the sprint folder to calculate the available man hours for the sprint. Determine the Target Story Points for the Sprint Based on the available resources, the team needs to decide on the target story points to complete for the sprint. If this is the team s first sprint, there won t be any historical data to help the team understand the team velocity, which is the number of story points the team can reasonably complete in a sprint. After a few sprints, the team s average velocity will emerge and can be used to more reliably predict output in future sprints. Each story needs to be small enough to complete in one sprint. If stories are too large, the Product Owner should break them down in to smaller stories before the team provides estimates. When you decide on a target, enter it on the Release Planning tab for the sprint folder. The target story points are displayed with the other release planning information when the sprint folder is selected. Managing Agile Projects in TestTrack seapine.com 23

26 One of the most important reports for an agile team is the Folder Task Board Report. Figure 21: Use target story points to estimate the relative size of the sprint effort. Add Report Hyperlinks to the Sprint Folder Description Add report hyperlinks so team members can run reports directly from the sprint folder Details tab. Report hyperlinks give team members a quick way to see the current sprint s progress. Figure 22: Add hyperlinks to run reports from the sprint folder. Managing Agile Projects in TestTrack seapine.com 24

27 Add High-Priority Items to the Sprint Folder Next, review the high-priority items in the product backlog and move them to the sprint folder. The sprint folder is the to do list, or sprint backlog, that drives what will be delivered at the end of the sprint. An easy way to add the high-priority items is to sort the product backlog folder based on priority, and then drag the stories to the sprint folder. Add Tasks for Completing Items Now that you know which items will be completed in the sprint, the team needs to add the tasks required to implement the sprint to the sprint folder. Team members should add enough tasks to get them started and keep the working going, but should stop once they hit a roadblock during decomposition. The team can modify tasks in the sprint folder throughout the duration of the sprint. Figure 23: Create tasks for everything required to complete an item. Provide Task Estimates Each task added to the sprint folder needs an estimate in hours. Work with the team to determine the number of hours it will take to complete tasks. Enter the Estimate event or a similar event to add the agreed-upon estimates and any notes to each item. Figure 24: Add estimates to tasks to specify how long it will take to complete them. Managing Agile Projects in TestTrack seapine.com 25

28 Addressing new issues is critical for ensuring all stories in a sprint can be completed on time. Keeping Sprints on Track During a sprint, the team works toward completing the tasks required to implement the stories they committed to. The Scrum Master plays an integral role in keeping things moving throughout the sprint by removing impediments and facilitating productivity. Following are some ways the Scrum Master can help keep sprints on track. Enable Team Members to Sign Up for Tasks The sprint will start with an initial set of tasks to complete for the selected stories. Once the sprint is underway, in addition to completing existing tasks, the team will continue to add and remove tasks throughout the duration of the sprint. Allowing the team to modify and volunteer for tasks gives them more ownership of their workloads. To enable team members to sign up for tasks: Add a Grab event to your workflow that clears the current assignment, doesn t change the item state, and doesn t open the event dialog box. Create a trigger that automatically assigns the item to the last user to enter the Grab event. When team members complete tasks and need more work, they can select an item and enter the Grab event to assign it to themselves. Figure 25: Create a Grab event to let team members grab assignments. Require Team Members to Report Remaining Work Team members should review their tasks every day and report the remaining time needed to complete them. To report this information, use the Enter Work event, which does not change an item s workflow state. Managing Agile Projects in TestTrack seapine.com 26

29 If time remaining isn t reported regularly, it s difficult to determine the sprint s status, even with daily Scrums. Without current data, the team can t make informed decisions about how to self-organize within the sprint. Daily Scrums and sprint burn downs help the team gauge progress, giving team members the opportunity to help each other so they can complete sprint objectives. Evaluate Progress at Daily Scrums Daily Scrums are the team s opportunity to evaluate sprint status, share what they re working on, what they plan to work on, and any roadblocks that are preventing progress. TestTrack includes several reports that are useful to share with the team during this meeting. Generally, the Scrum Master generates the following reports before each daily Scrum, but anyone who has time could generate them. Figure 26: View the sprint folder to evaluate project status. Burn Down Chart Burn down charts display work remaining. The chart should burn down to zero by the end of the sprint. As teams report task time, the burn down line fluctuates as it moves toward zero. Figure 27: Use burn down charts to determine when work will be complete and track the team s progress. Managing Agile Projects in TestTrack seapine.com 27

30 Folder Task Board Report Folder task board reports display the tasks team members owns and its state. This is one of the most important reports for an agile team because it shows the progress the team is making toward achieving its sprint goals. Figure 28: Use folder task board reports to review the status of owned tasks. This report has columns and rows for each folder included in the report. TestTrack also automatically groups the state of items in columns based on time tracking data. The following development states are used: Not Started The actual hours entered are zero and the workflow state attribute is Open. Keeping your agile artifacts updated will help everyone know the status of a release or sprint. In Progress The actual hours entered are greater than zero, the remaining hours entered are greater than zero, and the workflow state attribute is Open. Done The remaining hours are zero and the workflow state attribute is Open. Accepted The remaining hours are zero and the workflow state attribute is Closed. Release Status by Item Report Release status by item reports display much of the same information as folder task board reports, but in a more concise format. These reports Managing Agile Projects in TestTrack seapine.com 28

31 also include additional time tracking information such as Percent Done and Variance. Use this report to determine how much work remains in a release or sprint. Figure 29: Use release status reports to view the events and progress on individual items. Release status reports are based on folders with release planning fields enabled. They also require time tracking data and will be empty if no data is entered. Managing Agile Projects in TestTrack seapine.com 29

32 Managing New Issues and the Backlog As the team works on sprints, someone on the team, such as the Scrum Master, needs to manage new issues. The Product Owner should also keep the backlog organized and prioritized to avoid delays before the next sprint. Triage New Issues as Soon as Possible Addressing new issues is critical for ensuring all stories in a sprint can be completed on time. If a bug is found in a feature implemented during the current sprint, the team should fix it within the same sprint. If a bug is discovered in an existing feature, the team needs to decide how to handle it. During the sprint, it s also common to identify additional tasks that are required to complete a story. Proactively Manage the Product Backlog New items, such as new features, may be added to the product backlog throughout the project. Make sure the Product Owner reviews, organizes, and prioritizes these items as they are added. It s also important to review existing items in the backlog and reprioritize them as needed. Keeping the backlog up-to-date reduces preparation work for subsequent sprints and makes it easier for the team to focus on items that have the most value for your customers. Managing Agile Projects in TestTrack seapine.com 30

33 Completing Sprints and Releases In TestTrack, a sprint is complete when the tasks created for each story in the sprint folder are complete, and the Product Owner has reviewed the implementation of user stories and accepted or rejected the stories. The team will also conduct a sprint retrospective to review the sprint. Record the Final Status of Stories After the Product Owner, customers, and stakeholders review the implementation, you ll want to capture the final status of stories in TestTrack. Grouping stories by status and capturing the number of story points completed during the sprint will help you determine the team s velocity for future sprints. Here s how to record the final status: For a story that was completed and accepted, enter a workflow event that closes the story and indicates it was implemented and accepted, such as the Approve event. If a story wasn t started during the sprint, move it to the folder for the next sprint or move it back to the product backlog to be addressed later. If a story was partially completed during the sprint, enter a workflow event that closes it and indicates the story wasn t completed during the sprint or was rejected during review, such as the Reject event. You may also want to duplicate the story and add it to the folder for the next sprint. Review Team Velocity During the sprint retrospective, reflect on the current sprint results and decide how to improve going forward. If the team did not complete the number of story points they agreed to, determine the root cause. Velocity and cumulative flow chart reports provide data that will help pinpoint the cause. Velocity Chart Report Velocity charts graphically display the amount of work completed in each sprint over the duration of the project. Over time, the team s historical velocity can be used to plan future sprints and releases. Managing Agile Projects in TestTrack seapine.com 31

34 Figure 30: Use velocity charts to determine how many story points the team completed in each sprint. Cumulative Flow Chart Report Cumulative flow charts display the flow of work in progress through the different states (Not Started, In Progress, Done, and Accepted) over time. As items move through the states, the Not Started, In Progress, and Done bars should decrease in size and the Accepted bars should increase to indicate the team is making progress toward completing the sprint. Figure 31: Use cumulative flow charts to evaluate the progress of tasks over time. Managing Agile Projects in TestTrack seapine.com 32

35 Completing Releases In TestTrack, a release is complete when all sprints are completed, the customer provides approval, and the product is released. Whether the team releases every sprint or every few sprints, they will always have a demo and retrospective before closing out the sprint or release. Managing Agile Projects in TestTrack seapine.com 33

36 You re Now Ready to Manage Agile Projects with TestTrack After some initial configuration effort, you are ready to manage your agile projects with TestTrack. Keeping your agile artifacts organized and updated as a project progresses will help you and other team members understand exactly where a release or sprint stands at any point in time. After your first sprint, you will have valuable data and experience to help your team plan and manage subsequent sprints, while successfully releasing products on time that deliver value for the customer. Managing Agile Projects in TestTrack seapine.com 34

37 About Seapine Software With over 8,500 customers worldwide, Seapine Software, Inc. is the leading provider of quality-centric product development solutions. Headquartered in Cincinnati, Ohio, with offices in Europe, Asia-Pacific, and Africa, Seapine s development solutions help organizations ensure the consistent release of high quality products, while providing traceability, metrics and reporting, and compliance. Learn more at seapine.com. Managing Agile Projects in TestTrack seapine.com 35