Your privacy is important to us. We will never share your data.
Thank you!
Your message is highly valuable for us. One of our experts will follow up with you within 1-2 business days to discuss your request or to inquire for additional information if needed.
In the meantime, you might be interested in learning more about the following:
Our Blog
Check out new ideas and best practices for the IT world. Read more >
* Required fields
Your privacy is important to us. We will never share your data.
Thank you!
Dear %name%,
Thank you for your interest in our vacancies. You will receive weekly notifications based on your career preferences. We are looking forward to getting in touch with you.
Best regards, Recruiting Team
* Required fields
Your privacy is important to us. We will never share your data.
Thank you!
You are now subscribed to Infopulse Newsletter. Please look out for our email occasionally (and don’t forget to check your junk folder).
In the meantime, you might be interested in the following:
Infopulse continues a set of articles dedicated to Scrum and Agile methodologies. Previously, you could read our success story showing advantages of using Scrum in a fixed-price project. In the following article, we will show you how to manage Agile Software Development.
Regardless of the software development methods and your role (be it a developer, manager or a customer), it is important to keep the project under control. There are many platforms created for the proper tasks organization and monitoring. Discover our insights on Team Foundation Server (TFS) – a Microsoft platform, and your perfect choice for Agile projects.
TFS as a solution for managing the development lifecycle
Team Foundation Server (TFS) is an Application lifecycle management (ALM) product developed by Microsoft Corporation. It offers clear and adjustable tools to plan and monitor projects and individual tasks, making TFS a perfect choice for both Agile Software Development and Waterfall teams.
Organization of the requirements in TFS
All projects begin with planning, i.e., defining requirements and restrictions such as project duration and availability of resources and ending with the release and reporting phases. At the same time, the course of the project development may vary as it largely depends on specifics of methodologies applied and way of their implementation according to the main project requirements. Thus, one of the primary features of Scrum is a Product Backlog, which outlines all future work to be conducted throughout the whole project.
The Product Backlog is a roadmap and storage of all customer’s requirements, expectations, and priorities displayed in a form of User Stories. Each User Story contains a part of the requirements, which can be realized independently. As some projects may contain up to 2,000 User Stories, all tasks are represented in the Requirements Tree to simplify managerial processes.
TFS Requirements Tree consists of Releases, Epics, Features, and Product Backlog Items (Stories).
Picture 1: TFS Requirements Tree
Picture 1 shows an ordinary Backlog containing a number of Features, which form a part of Epics. Each Tree Item can have a value in the Business Value field that shows its relative importance in the frame of the whole project. As clients’ representatives with various access rights take part in the project, they frequently influence the Business Value field. The tree structure streamlines requirements search and updates, making it possible to specify the priority level of specific requirements and to present the project scope at different levels. Thus, the customer can check current reports, the supervisor can see features that are currently in the pipeline, and the Director can track the status of the Calculation Engine.
At the planning stage, a project can contain a number of Releases, Features, and Epics, which may be moved flexibly depending on the business priorities, while considering available resources and efforts needed to meet the requirements. As Releases, Features, and Epics generalize the requirements to represent them at different levels and with different details, a User Story is an indivisible unit available for teamwork.
User Story Requirements form a set of criteria, according to which your team can estimate the work scope, deadlines, complexity, and interactions. Please note that refining specification requirements and expectation descriptions always requires a lot of time. A common practice is to cease writing Acceptance Criteria field specifications as soon as the development team gets a clear understanding of a User Story. This implies the team should have the following: experience in realization of similar scenarios; rights to make independent implementation decisions; and ability to make valid estimations of project complexity. That is to say, if the team is already familiar with the terms and definitions of the criteria, and knows where to get the data, there is no need to spend more time on documentation.
Picture 2: User Story example
In our next article, we’ll continue speaking about Project Planning and Monitoring with Team Foundation Server. Stay tuned to learn more about how to estimate the scope of work with TFS!
Originally published May 15, 2017 Updated November 13, 2018