August 10, 2010 at 17:02Scrum implementation in TrackStudio
This article is about how you can use TrackStudio to develop software using the Scrum methodology. TrackStudio is a universal task management system and Scrum is one example of usage. You will need a TrackStudio instance ( 90-day trial ) and configuration . After downloading, you need to install TrackStudio and roll the configuration according to the instructions.
In accordance with the Scrum methodology, the system defines three roles: Product Owner (Customer), Scrum Master (Master) and Team (Team).
The task of the Product Owner or the Customer is to register history in the system and determine their importance for the product. The customer interacts with the team (Team) for the most complete understanding by the team of the goals of the customer, and the customer - the capabilities of the team. The result of this interaction should be clearly formulated and ranked by importance of history, which the Customer and the team understand the same.
The master is a bridge between the Customer and the team, he plays a major role in sprint planning, determines his budget and distributes stories on the team.
Each participant in the development team, when planning, evaluates the tasks that he understands, indicating the task budget in hours. Upon completion of planning, each participant is engaged only in their tasks.
The system defines projects, stories, sprints and tasks. The projects are managed by the Customer. He writes stories. Sprints are created by the Master, but he fills them with stories. Tasks can be created by team members inside sprints and inside stories.
The customer creates stories, fully and clearly describing them. In this case, the fields “How to demonstrate” and “Importance” are required. The Importance field must contain any integer, the larger it is, the higher the importance.
Then the team reviews the tasks created by the Customer and evaluates their complexity, indicating the budget. At the same time, team members see each other’s ratings and can focus on them, or they don’t see and rely only on themselves.
The system tells which tasks have already been evaluated by this participant and which are not yet.
Unlike the traditional Scrum methodology, the Customer does not determine the complexity of the history, but sees the estimates of the complexity and can participate in their discussion.
The master creates a sprint in which the Customer, in discussion with the Master and the team, indicates deadlines. By the indicated time sprint should be ready for demonstration. Based on the timing and performance of the team, the Master indicates the sprint budget. At the same time, he focuses on the indicator “You can plan” the table “Planning” in the sprint. The sprint budget should be less than this estimate.
After all or almost all participants rated the stories, the Master begins to fill out the sprint, transferring the most important tasks for the Customer to it. The budget of the stories at this stage is not approved, it is still a matter of discussion. Transferring the stories to the sprint, the Master sees the first estimate of the sprint budget and compares it with the given one. At this stage, it is already possible to imagine which stories will be included in the sprint and which ones will not.
Then the Wizard begins to distribute stories among performers and approve task budgets.
At the same time, he can be guided by both the estimates of the team members, choosing as the responsible one who indicated the shorter time, and the team workload table. At the same time, the Master can indicate the budget based on his estimates.
Sometimes the user included in the team works not only on the project of this Customer, but also on other projects. In addition, in some teams, different users work a different amount of time (not everyone sits at work from 9 to 18). To take this into account, for each user there is an additional field “Degree of employment”. It indicates the number of working hours for the user per week. Those working hours when they work, but are not present at work - this is important for sprint planning.
After the sprint tasks are distributed, it may turn out that more of the tasks are hanging on one of the participants than he can perform. In this case, you need to either review the budgets of the stories of this participant, or reassign some of the tasks to another participant, or decompose the largest tasks and distribute them according to the team.
Also, of course, it may turn out that the “party budget” in planning has been exceeded. In this case, you should either increase the sprint budget (if the time margin allows), or change the estimates of some stories, or remove some of the least significant stories from the sprint.
At the end of sprint planning, the Wizard starts the sprint and the team can start its tasks.
The master can monitor the progress of the sprint and respond in a timely manner to lagging behind the plan. If more than planned time was spent on the story, this time will be marked in red. When a team member completes all his tasks, the Master can reassign tasks of other participants who are behind schedule.
After all the stories in the sprint are implemented, the Master will be able to close the sprint and, together with the team, begin to demonstrate the results to the Customer.
In accordance with the Scrum methodology, the system defines three roles: Product Owner (Customer), Scrum Master (Master) and Team (Team).
Product owner
The task of the Product Owner or the Customer is to register history in the system and determine their importance for the product. The customer interacts with the team (Team) for the most complete understanding by the team of the goals of the customer, and the customer - the capabilities of the team. The result of this interaction should be clearly formulated and ranked by importance of history, which the Customer and the team understand the same.
Scrum master
The master is a bridge between the Customer and the team, he plays a major role in sprint planning, determines his budget and distributes stories on the team.
Team
Each participant in the development team, when planning, evaluates the tasks that he understands, indicating the task budget in hours. Upon completion of planning, each participant is engaged only in their tasks.
Backlog
The system defines projects, stories, sprints and tasks. The projects are managed by the Customer. He writes stories. Sprints are created by the Master, but he fills them with stories. Tasks can be created by team members inside sprints and inside stories.
How it works
Filling product backlog
The customer creates stories, fully and clearly describing them. In this case, the fields “How to demonstrate” and “Importance” are required. The Importance field must contain any integer, the larger it is, the higher the importance.
Then the team reviews the tasks created by the Customer and evaluates their complexity, indicating the budget. At the same time, team members see each other’s ratings and can focus on them, or they don’t see and rely only on themselves.
The system tells which tasks have already been evaluated by this participant and which are not yet.
Unlike the traditional Scrum methodology, the Customer does not determine the complexity of the history, but sees the estimates of the complexity and can participate in their discussion.
Planning
The master creates a sprint in which the Customer, in discussion with the Master and the team, indicates deadlines. By the indicated time sprint should be ready for demonstration. Based on the timing and performance of the team, the Master indicates the sprint budget. At the same time, he focuses on the indicator “You can plan” the table “Planning” in the sprint. The sprint budget should be less than this estimate.
After all or almost all participants rated the stories, the Master begins to fill out the sprint, transferring the most important tasks for the Customer to it. The budget of the stories at this stage is not approved, it is still a matter of discussion. Transferring the stories to the sprint, the Master sees the first estimate of the sprint budget and compares it with the given one. At this stage, it is already possible to imagine which stories will be included in the sprint and which ones will not.
Then the Wizard begins to distribute stories among performers and approve task budgets.
At the same time, he can be guided by both the estimates of the team members, choosing as the responsible one who indicated the shorter time, and the team workload table. At the same time, the Master can indicate the budget based on his estimates.
Degree of employment
Sometimes the user included in the team works not only on the project of this Customer, but also on other projects. In addition, in some teams, different users work a different amount of time (not everyone sits at work from 9 to 18). To take this into account, for each user there is an additional field “Degree of employment”. It indicates the number of working hours for the user per week. Those working hours when they work, but are not present at work - this is important for sprint planning.
After the sprint tasks are distributed, it may turn out that more of the tasks are hanging on one of the participants than he can perform. In this case, you need to either review the budgets of the stories of this participant, or reassign some of the tasks to another participant, or decompose the largest tasks and distribute them according to the team.
Also, of course, it may turn out that the “party budget” in planning has been exceeded. In this case, you should either increase the sprint budget (if the time margin allows), or change the estimates of some stories, or remove some of the least significant stories from the sprint.
Launch
At the end of sprint planning, the Wizard starts the sprint and the team can start its tasks.
The master can monitor the progress of the sprint and respond in a timely manner to lagging behind the plan. If more than planned time was spent on the story, this time will be marked in red. When a team member completes all his tasks, the Master can reassign tasks of other participants who are behind schedule.
After all the stories in the sprint are implemented, the Master will be able to close the sprint and, together with the team, begin to demonstrate the results to the Customer.