How to use Agile-Team™ for Scrum
How to use Agile-Team™ for Scrum Version 2.04 Content Introduction ...........................................................................................................................................................................3 A Scrum Project in Agile-Team™ ............................................................................................................................................4 Product Backlog .....................................................................................................................................................................5 Roadmaps and Releases .........................................................................................................................................................7 Sprint Planning - First Step - Selection of Work Items for a Sprint ........................................................................................8 Detailed Estimating ................................................................................................................................................................8 Activities .................................................................................................................................................................................9 Sprint Properties ....................................................................................................................................................................9 Resources ...............................................................................................................................................................................9 Allocating Resources to Projects (Resource Management) .................................................................................................10 Priorities Within a Sprint ......................................................................................................................................................11 Assignment of Resources to Individual Activities (Tasks) ....................................................................................................11 Calculating a Schedule for the Roadmap, Releases, and Sprints .........................................................................................11 Daily Scrum Meetings ..........................................................................................................................................................12 Team Member’s View ..........................................................................................................................................................13 Reporting Spent Time ..........................................................................................................................................................13 Burn Down Chart’s ...............................................................................................................................................................14 Drill Down and Analyzing Work............................................................................................................................................14 Sprint Review .......................................................................................................................................................................14 Sprint Retrospective .............................................................................................................................................................15 Other Useful Features of Agile-Team™ Not Described in Scrum .........................................................................................15 Rule Checking for Problems .................................................................................................................................................15 Version Support ...................................................................................................................................................................15 Defect Management ............................................................................................................................................................16 Helpdesk Customer Portal ...................................................................................................................................................16 Using a Helpdesk System for Communication with the Users .............................................................................................17 Using Multiple Hierarchical Project Dimensions in Agile-Team ...........................................................................................18 Knowledge and Documentation Management - the Procedures Folder .............................................................................18 Permissions and Security .....................................................................................................................................................18 Summary of Agile-Team™ ....................................................................................................................................................19 How to use Agile-Team™ for Scrum Page 2 of 20 Version 2.04 Introduction This document illustrates how the unified project management tool Agile-Team™, can be used to manage a Scrum development process. For a description of Scrum, please see: http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf (Short and easy) http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf (Long and detailed) http://www.mountaingoatsoftware.com/topics/scrum (Very good materials) http://en.wikipedia.org/wiki/Scrum_(development) Also, there are many excellent documents and videos about Scrum available on the Internet. Simply type the keyword "Scrum" into your favorite search engine in order to locate the latest documents and videos. Scrum: is a lightweight iterative process used to manage and monitor development; iterations are called Sprints, and are fixed intervals, from 1 to 4 weeks; focuses on good communications, inherently handling conflicting interests and needs; lets the business prioritize project tasks based on business value; focuses on working software since each Sprint results in a functional software component; provides project clarity since each Sprint demonstrates functional software; focuses on removing obstacles for the project through good communications and ongoing user input; is lean, with only three defined roles (a Scrum Master a Product Owner and a Team); can scale to support very large projects, by having a group of teams and more Sprints; can be used to develop new software, or new releases of existing software; and is highly successful based on past experiences. For a description of Agile-Team™, please visit the official product web site at www.agile-team.com. How to use Agile-Team™ for Scrum Page 3 of 20 Version 2.04 A Scrum Project in Agile-Team™ Agile-Team™ is a sophisticated application that organizes project data, such as Work Items and Resources, in a common database. It can organize and present the stored project data in many different ways to support the different needs and processes in the individual organizations, teams and projects. The following is an example screenshot from the Agile-Team™ Work Item Explorer showing the organization of a Scrum project: Comments: 1. The Selector Panel contains a list of dimensions (Project, Resource, Phase, etc.), which can be used to structure the project data. What is shown in the Work Item Explorer is a combination of the dimension nodes “selected” in the selector and the filter applied ( ). The status bar at the bottom of the window will always display the current selections and filter. 2. In the project's dimension, a folder is created to store the project (We use the name “Scrum Project”). Under the “Scrum Project” folder, we create four subfolders: “Impediments”, “Product Backlog”, “Incoming” and “Roadmap”. We organize the “Sprints” in release subfolders under the “Roadmap” subfolders. Work Items can be easily moved between folders by simple, intuitive drag and drop operations. 3. The Work Item list shows the selected and filtered work items. These work items can be grouped and sorted by any column. The columns to be displayed can be chosen by using the How to use Agile-Team™ for Scrum toolbar button. Page 4 of 20 Version 2.04 4. The view selector can be used to choose between many different views of the work item list, including open items, done items, all items done from one version to another version, known issues in a version, my items, time usage last 6 months or weeks or days, or a Gantt plan, etc. Views can be customized and new can be created. 5. The Work Item Pane shows the properties for the currently selected Work Item. The Work Item Pane layout can be customized to the needs of individual projects. Product Backlog In Agile-Team™ a Product Backlog is represented as a folder that contains a list of feature requests, wishes, and ideas – in other words, a list of work items needed to be performed in order to build the desired product. The Backlog can, if desired by the team, also contain identified bugs, which must be fixed. The Product Backlog should be updated and changed, as long as the project is alive. The Product Backlog is considered to be dynamic since it reflects the product knowledge at any given point in time. The input to the backlog can come from a variety of sources. Users and customers may suggest changes and new features based on own needs. The internal IT organization may propose security related items and other system properties; the Marketing department may make suggestions based on competing products and market knowledge. Bug reports can come from many places. Only the Product Owner should update the Product Backlog. In the “Incoming Requests” folder, everybody can enter new items. The Product owner processes and moves the items from the “Incoming Requests” folder to the Product Backlog, and oversees updating of the descriptions and priorities for these items. It is the Product Owner’s responsibility to ensure that all items have a clear description, and are assigned a proper “priority” according to their individual business value. The Product Backlog should be visible to all project participants. The following Agile-Team™ properties are relevant to managing the Product Backlog: User Description: These are typically a mixture of User Stories, requirements, detailed functional descriptions, or other user input, descriptions can be plain text, but also MS Word documents with inline MS Word editing. Business Value (BV): The Product Owner can assign a “Business Value” for each item in the product Backlog. The Business Value indicates the importance of having the associated item implemented. The Business Value is a flexible numeric value that can be a simple sequential numbering ( i.e. 1,2,3,4,5… or 1,1,2,2,2,3,3,4,4,) or a value range ( i.e. 1..1000,) to or actual money values, i.e. $100, $1,000, $100,000. Estimate: All items in the Product Backlog must have a rough estimate of the amount of hours it will take to implement that Item. The estimate represents the size (or the cost) of the associated item. The estimate must be created by the team who will be doing the work, but in close collaboration with the Product Owner to ensure that the work are thoroughly understood. The estimates must be realistic, and contain a buffer to handle unexpected issues, as well as a margin to reflect varying skill levels of the implementation personnel. Estimates should also include the time for required testing, review, and 1 documentation activities, etc. for each Item . 1 Often the technique “Planning Poker” is applied for creating the initial estimates. Planning Poker, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development. Refer to the Wikipedia entry at http://en.wikipedia.org/wiki/Planning_poker for details. How to use Agile-Team™ for Scrum Page 5 of 20 Version 2.04 2 It is necessary to decide whether estimates should be handled as “Points” or “Ideal Time.” Both of these concepts are supported by Agile-Team™, and described in detail in the references listed above. In agile Team Points and Ideal Time estimates are implemented in a straightforward way: 2 When using Points you assign each item a size that is relative to the size of the other items. A well-known piece of work has the size 1 (like, for instance, a known dialog,) and an item of size 3 is then expected to take 3 times as long time. During the first Sprints in the project, the team learns how many hours they actually need to implement each point including all the time that is needed for detailed design, testing, documentation, etc. Using Ideal Time, the estimate of each item is the number of hours each item will take if the team works on nothing else but the item, which is the actual time/effort exclusive of overhead - no emails, meetings, maintenance, tool updates, etc.) Agile-Team™ is a very powerful tool for using ideal time because it integrates time reporting, resource management, and automatic planning, so it is possible to see how long time any and all completed items have taken to complete and it is possible, to see how much time is actually used for maintenance, meetings overhead items etc. - more about this later. The property “Budget” can be used to hold the Ideal Time estimate for each item in the product backlog. Alternatively the property “Points” can be used to specify the Story Point estimate for an item. EstimationRisk: This property can be optionally used to show how sure the team is about the estimate. For instance, this value can reflect if the team has done a similar thing before and they are very sure about the estimate, or this is new and unknown technology that can give surprises. ErrorSeverity: For bugs, this property indicates the user's severity level for the problem: Low, Normal, High or Urgent. (Note that the priority in some situations can be different for the team than for the user.) Originator: The person who is the source of the Item. CreationDate: Agile-Team™ will automatically log, when the Item is created. CreatedBy: Agile-Team will automatically log who created the Item. The following description of these concepts is rudimentary. For a more detailed description, refer to the references provided in the above. How to use Agile-Team™ for Scrum Page 6 of 20 Version 2.04 In Agile-Team™, a typical view to the Product Backlog could look like: Notes: The standard “Backlog” view is chosen, because this has a sorting on the Order column, the items can be reordered by drag and drop operations with the mouse (Notice that we can see that the “Reordering Mode” flag is raised in the bottom status bar.) Other Backlog views can be chosen or created. For instance, as example it might be very relevant to group on Originator, EstimationRisk, or other dimensions (like a Customer or a Part structure for the application to understand things better). Also, sorting on the property BV/Budget makes it clear what gives most Business Value for the amount of work. The actual view should fit the individual team and project to give the best insight in the needed work. Roadmaps and Releases A Roadmap is a series of Releases, and each Release consists of a series of Sprints. The initial Sprint(s) in a new project will probably focus on some initial design and foundational architecture for the application, while the last Sprint in a Release is typically used for stabilization and maybe commercial release preparation3. In Agile-Team™, it is suggested, that the Roadmap, Releases, and Sprints are implemented as individual folders. Planning for Releases consists of moving items from the Product Backlog to the Release backlogs and planning of Sprints consist of moving items from the Release Backlogs to the actual Sprints. 3 Note that the Release and Roadmap strategy outlined here is a recommendation only. The actual strategy to apply should be decided on by the team working on the project. Some teams will chose to just have a series of Sprints and making Releases from time to time. How to use Agile-Team™ for Scrum Page 7 of 20 Version 2.04 Sprint Planning - First Step - Selection of Work Items for a Sprint The objective of an agile process is to maximize early Business Value delivery. Agile-Team™ supports this objective through the property “BV/Budget”, where the Business Value (BV) property is compared with the cost Budget (i.e. cost,) represented as (Budget in Hours). By sorting on the BV/ Budget column, it can be seen what Work Items give most value relative to its cost. To assist in the selection, Agile-Team™ can bring up a graph that visualizes the value versus cost equation (BV/Budget). The resulting line represents the break-even point for the number of available hours for the Sprint. The Items above the line (in green) are those that give most value relative to cost, and, therefore, probably, should be included in the current Sprint, whereas the items below the line (in red) should, maybe, be included in a future Sprint. It should be noted that the team should probably include some other Work Items, which do not directly deliver value such as restructuring or developing internal documentation etc. These Work Items should be included in the Sprints with the consensus of the Team and the Product Owner, but maybe not having assigned a Business Value. Bugs can be handled in several ways. For instance, we can choose to include some bug fixing in each Sprint, or you can dedicate some Sprints entirely to bug fixing4. Detailed Estimating One of the first tasks to be performed during the initial Sprint planning is to break large Work Items up into smaller items. Perhaps all Work Items larger than 25 hours should be broken into smaller items, since large items are difficult to estimate correctly. Agile-Team™ allows you to add Child-nodes to a Work Item at any time, retaining all logic and values of the affected Work Items. This allows a task to be easily sub-divided. Naturally, a parent Work Item will only be flagged as completed, when all the children are finished, and the estimate of the parent will be the sum of the estimates for the children. Furthermore, where applicable, settings for the parent will be inherited by the children.) This allows the job to be easily subdivided when needed. 4 There is some discussion about the timing of bug fixing in Agile/Lean best practices, but the consensus seems to be that bugs should be fixed as early as possible, and, therefore, bug-fixing should be part of on-going Sprints. How to use Agile-Team™ for Scrum Page 8 of 20 Version 2.04 Activities In Agile-Team™, a Work Item has activities which each have assigned resources and estimates. In the example on the right, each Work Item has four activities (Implementation, Documentation, Testing, and Review). This is optional as only a single activity is required, but the four activities supports a workflow to remember that relevant items must be documented, tested and reviewed. Sprint Properties Right clicking on a project folder in the selector allows you to specify the properties for the folder. This is used to set the properties for each Sprint folder. Under Description, there should be added a description of the Goal for Sprint, so everyone have the same understanding of the goal for the Sprint. Under the tab “Time Constraints”, it can be specified what is the total Budget in number of hours, what is the start date (Earliest Start) and what is the completion date (Latest Finish). Resources In project management terminology people are referred to as Resources. In Agile-Team™, the resources are shown and managed in the Selector Panel’s Resources tab. Groups of resources can be created, a resource can belong to multiple groups, and a group can contain other groups. AgileTeam™ groups can be used to define the teams, define groups of resources with a specific skill or just grouping resources together for any good purpose. In the example, below, the resources, who participate in the Scrum project, are Anders, Eva, Leo, Michael, and Peter. How to use Agile-Team™ for Scrum Page 9 of 20 Version 2.04 Agile-Team™ provides for detailed calendar management so each person’s working calendar can be modeled, including periods with part time work, holidays, vacations etc. so the scheduling algorithm will only take actual working hours into consideration. Allocating Resources to Projects (Resource Management) The simplest resource allocation scenario is when resources are immediately available to work 100% on a project. Unfortunately, however, in most cases resources can start on a project only after they have finished a previous project, or 5 they can work on a given project only for a certain time-period, and have to work on multiple projects simultaneously .. Agile-Team™ has powerful functionality for allocating resources to projects, enabling it to manage complex resource allocation situations with simple methods. By clicking on the button “RA Pane” it is possible, to specify a prioritized list of allocation to projects for each resource: 5 For instance, software developers available work time is often divided between development and bug-fixing. How to use Agile-Team™ for Scrum Page 10 of 20 Version 2.04 th st In this example “Anders Andersson” has as his first priority his holiday from 19 to 31 December. As his second priority he is allocated 30 hours per week to work on the “Scrum Project”. Specifying 30 hours per week out of a weekly norm of, perhaps, 40 hours per week gives a buffer, and relates to what Scrum defines as the velocity of a project or the ideal hours that can be expected to development work. With the combination of the parameters Priority, Start, End, Load and Hours it is easily possible to specify all normal resource allocations. The scheduling algorithm takes into consideration the allocation of resources to projects, and calendars for the individual resources, and uses this information to automatically assign and schedule resources to Work Items and activities. Priorities Within a Sprint In Scrum each Sprint is a little waterfall project. Sprints start with design, then implementation and test and review in the end. However, most important items should be performed first, since the Sprints will always finish on a given date which is known from the beginning. Within a Sprint most team can handle the planning, since Sprints are short. However, the priority of the Work Items within a Sprint can be specified by the Priority property for each item. The scheduling algorithm will plan the Work Items within each Sprint based on priority (with a lower values reflecting a higher priority.) All items with same priority are just scheduled to start at the same time. Please note that in Agile-Team, Work Items can also be linked together with predecessors, but it is not recommended to use such constraints more than absolutely necessary. In any project management tool, when there is a network of links, it can be difficult to understand and maintain, and it can sometimes be difficult to understand the planning results. However in the few situations, when ex. professional services relate to things that must be developed, using a few links can be useful and relevant. Assignment of Resources to Individual Activities (Tasks) Resource assignment should not be more detailed or done earlier than needed. For the activities where it has not yet been determined who will perform the job, these are assigned just to the relevant group of resources. When it is known who will carry out some activities, these can then be assigned to specific resources. By assigning work to groups for long time planning, and to individual resources in the near term, Agile-Team™ facilitates both short term and long term planning. Calculating a Schedule for the Roadmap, Releases, and Sprints Now, once Work Items have been entered, estimated, prioritized, and assigned, and team members have been allocated to the project, we can have Agile-Team™ automatically calculating a schedule by a clicking on the How to use Agile-Team™ for Scrum toolbar button. Page 11 of 20 Version 2.04 By clicking the show Gantt toolbar button, Gantt bars are shown for the Work Items: From the Gantt, it is easy to see how much margin (or maybe overload), there are for each sprint and each release, so proper actions can be taken. Notice that Items in the Product Backlog are not taken into account for the plan calculation, since no resources are allocated to this. Daily Scrum Meetings A Scrum team should meet each day for a daily standup meeting, review the priorities and decide who is going to work on what tasks. Each member is typically asked: What did you do yesterday? (Can anything be marked done?) What will you do today? (What new job to pick?) Is anything in your way? (Who can help?) The purpose is to hold a short meeting in order to collect a quick status update, not to do detailed problem solving, and not to give a complete project status to a project manager. The Agile-Team™ Task Board is a convenient tool to support the Daily Scrum Meeting; the team members can explain what they did yesterday, and then use the Task Board to move items to Done state, and when discussing what to do next, they can use the Task Board to drag new items to themselves. The Task Board can also be used to support a Daily Scrum Meeting in a distributed team, where the team members are looking at the same electronic Task Board. The Agile-Team™ Task Board is a convenient tool for quickly assigning work to people and to change the status of a work item by simple dragging and drop. How to use Agile-Team™ for Scrum Page 12 of 20 Version 2.04 Team Member’s View Through the “MyTasks” view that can be customized to the needs of each individual user, each team member can see a descriptive list of the Work Items that are assigned to that individual: The Work Items can be sorted on the attribute Start Date, which will reflect the order of the assumed execution, even when a resource works on multiple projects and where Items are assigned a different priority. Reporting Spent Time Agile-Team™ makes it easy to report time on the individual work items. When used time is reported, the remaining time estimate is automatically updated but can also easily be specified if different than the automatically calculated. Time can be reported in the dialogs directly for the individual items, but AgileTeam™ does also provides a daily time reporting view that shows all items that are active for each person for the given day, across all projects: Further, there is a monthly time report view, which shows the accumulated time usage and balance for each resource: How to use Agile-Team™ for Scrum Page 13 of 20 Version 2.04 Burn Down Chart’s When used time have been reported on the individual items, and remaining estimates have been updated then AgileTeam™ can automatically generate “Burn Down Chart’s” for the projects, releases and the sprints. Through the “Time Chart” report, Agile-Team™ can display how the values of Rest, Used, Total, and Budget are developing over time. The rest time trend can be used to estimate when the team will finish the Sprint. Drill Down and Analyzing Work Agile-Team™ has many tools and reports to facilitate the drilling down into the details of the project data. For instance, it is possible to inspect how much time was actually spent on individual Work Items compared with estimates, how is the workload distributed between the team members, how many bugs was introduced in the last version, etc. Sprint Review In Scrum, each Sprint should end with a Sprint Review, where all the new functionality developed in the Sprint is demonstrated. Agile-Team™ produces a list of what has been completed in the Sprint, and the stored user descriptions can serve as a documented guide for demonstrated features. How to use Agile-Team™ for Scrum Page 14 of 20 Version 2.04 Sprint Retrospective At the end of every Sprint, a Scrum team should have a retrospective session to determine how it is doing and where improvements to the process can be made, considering, for instance: whether there is something new the team should start doing, whether there is something the team are doing that should be stopped, and, what works well for the team and should continue. The many features of Agile-Team™ supporting drill down, analysis and planning can greatly assist in analyzing the situation and provide input for the Sprint Retrospective. Other Useful Features of Agile-Team™ Not Described in Scrum When starting to use Agile-Team™, we recommend using the minimum number of features and sticking as closely to the bare-bone Scrum feature set. However, as the rate of project adoption increases, more Agile-Team™ features should be applied. In the following pages some more features of Agile-Team™ will be shown. Rule Checking for Problems Agile-Team™ can help to spot many problems for the projects like potential budget overruns, delays or just that some actions are needed to assign resources to tasks etc. These problems are be visualized in the Agile-Team™ system. One special location is in the Work Item Explorer where the very left column has some squares that will be marked with yellow as red if problems are detected. Version Support For some software development projects, it is important to keep track of what has been done and what are the known problems in each version of the software product being produced. Agile-Team™ has a built in Version Dimension for representing the versions. By automatically coupling the work items to versions, a number of views, queries and information will then be possible, like: See the history of released versions for a product. For bugs – in which version did they appear – in which version are they solved? For Tasks - in which version are they done? Provide better Release Notes - what was done between any two versions? Knowledge Base - what are known issues in each individual version? If you don’t need version support in your projects, you don’t need to worry about this in Agile-Team™. How to use Agile-Team™ for Scrum Page 15 of 20 Version 2.04 Defect Management If you are developing software, you will have to deal with bugs, no matter how good your testing and quality assurance procedures are. It is a good practice to fix bugs as quickly as possible, but for various reasons there will often be a list of known bugs. Agile-Team™ provides excellent views to manage defects, and can also manage relating of bugs and fixes to branches is the source code. Helpdesk Customer Portal The comprehensive help-desk application that comes bundled with Agile-Team™ provides a portal for end-users to add change requests, report bug, and see status of existing change requests and bugs. Furthermore, customers can view release notes for new versions of the software as well as known bugs and reported problems for a given version of the software: How to use Agile-Team™ for Scrum Page 16 of 20 Version 2.04 Through settings, a team can specify that change requests and reported bugs by the end-user appear in the team's incoming folder in Agile-Team™. Using a Helpdesk System for Communication with the Users The ICT organization must continuously strive to optimize the quality of their service. One way of dramatically improving the level of service is by improving the communications flow with users, allowing, for instance, the users to see, in realtime, the status of their individual request. This not only increases transparency and accountability, but it also forces a structure upon the communication with users, which enables seamless resource changes in the ICT organization. The Helpdesk portal solution can be used for implementing this sort of communications flow. Below we see, for instance, a real-time view of all issues recorded in an instance of the Helpdesk portal solution. When we looking into one of the open issues, we can see the structured communication flow helping us keep track of issues and information. How to use Agile-Team™ for Scrum Page 17 of 20 Version 2.04 Using Multiple Hierarchical Project Dimensions in Agile-Team Agile-Team™ employs a powerful concept to handle and consider projects and work items from multiple dimensions. Agile-Team™ allows you to see, plan, operate, analyze and report in your preferred structure and viewpoint. There are predefined Dimensions such as Work Breakdown Structure, Parts, Phases, Resources, but you have a possibility to define as many custom Dimensions as you want. As example if you are using an agile process with backlogs and a number of releases and iterations, then it is convenient to be able to structure all the work items according to the components and structure of your application. New dimensions can for example be Contracts, Departments, Customers, Countries, and Work types. The dimensions make it easy to see all Issues/bugs/tasks as example for all projects in a single contract, in a given release of the software, for a given customer etc. Plans can be inspected and managed in any groupings. Knowledge and Documentation Management - the Procedures Folder Most often organizational knowledge and documentation is stored in an Intranet-based solution external to the project and process management tool being applied. However, AgileTeam™ allows the team to store information and knowledge for the projects in a built-in knowledge base repository. Here is an example about how MS Word can be triggered from Agile-Team and used to edit a procedure, which, when saved, becomes part of the Agile-Team™ knowledge base repository. Permissions and Security Most areas and operations in Agile-Team™ can be controlled by permissions, and it is possible to grant permissions to individuals as well as groups. So if you log external consultants into your projects management system, you can grant them access to only the projects they are working at. How to use Agile-Team™ for Scrum Page 18 of 20 Version 2.04 Summary of Agile-Team™ With a fully flexible folder structure with inheritance of properties, support of user defined dimensions, groupings on any property and strong customization possibilities it is possible to support most projects situations in a direct and intuitive way. The strong resource management concept allows handling of shared resources across teams in the enterprise. The integrated customer portal facilitates good customer contact. Agile-Team™ is an integrated and unified project management, bug tracking and helpdesk system with many features. You can start simple, and turn on features as you need them. With Agile-Team™ you can: Handle all stories, tasks, bugs, issues, projects and resources in one common database. Provide project visibility and a single source of real-time information to all roles in the organization. Pick and chose the best project/process approach for each team in the enterprise (Agile, Scrum, Lean, Waterfall, etc.) Spot potential budget overruns and project delays early. Use automatic scheduling, and handle resource management across the enterprise. Easily change priorities of projects, tasks and resources. Create reports, charts, burn downs, and Gantts. Provide a portal to your customers for incident and issue management. Get full life-cycle workflow support for issues reported by customers. Get extensive support for time tracking and reporting. Get extensive support for version management. Support outsourcing and separated teams. How to use Agile-Team™ for Scrum Page 19 of 20 Version 2.04 Europe H.J. Holst Vej 3-5C DK - 2605 Broendby, Copenhagen Denmark +45 36 36 00 00 [email protected] [email protected] Americas Agile-Team USA, Inc. Maryland United States Phone: +1 (904) 274 0264 [email protected] [email protected] Russia 5-th Sovietskaja str., 45, office 102 191024, St.Petersburg, Russia Phone: +7 (812) 710 38 43 [email protected] [email protected] How to use Agile-Team™ for Scrum Page 20 of 20
© Copyright 2024