Tasks
Once the value has been identified in a Backlog Item, we now know "what" we want and "why" we want it; and it is time for us to begin defining "how" we're going to do it. The Tasks are a way to plan "how" the work will get done. Typically there are many small pieces of work that must be done in order to accomplish the value of what was defined in the Backlog Item. Each of these small pieces should be independently testable. These bite-sized pieces of work are the steps we capture in the Tasks.
Break down the individual steps
It can be helpful to think of an end result being made up of a bunch of smaller steps. But how small of steps should be considered? We recommend making them small enough that they can be individually tested, yet a visible step toward the end-goal.
It can be helpful to think of an end result being made up of a bunch of smaller steps. But how small of steps should be considered? We recommend making them small enough that they can be individually tested, yet a visible step toward the end-goal.
Enable multiple people to work independently
By separating the Tasks into work that multiple people can do independent, it enables the team to get more done in less time. Tasks can be a great way to separate work that must be combined in the end, but can be done separately for most of the time.
By separating the Tasks into work that multiple people can do independent, it enables the team to get more done in less time. Tasks can be a great way to separate work that must be combined in the end, but can be done separately for most of the time.
Decide how the step can be tested
To know that work is finished for a given step, there must be some way to test that it is finished. Some condition that, when met, verifies that it is done. This is essential in keeping the work flowing. When a Task is open-ended, it can drag on for far too long, and never feel satisfying to call complete. Create each unit of work as something that can be seen, even if it is just by a peer team member.
To know that work is finished for a given step, there must be some way to test that it is finished. Some condition that, when met, verifies that it is done. This is essential in keeping the work flowing. When a Task is open-ended, it can drag on for far too long, and never feel satisfying to call complete. Create each unit of work as something that can be seen, even if it is just by a peer team member.
Task Lifecycle
Scrumly goes beyond a simple checklist by helping you manage the lifecycle of the Task in simple step-by-step fashion. This can help keep team members on track, and ensure they can pick right up where they left off. While it may seem like a rigid set of phases, it actually is what our human brain does anyway. It follows the scientific method in some ways, and provides a clear path to complete work.
Analyze
There must be some analysis that is needed before work can be done. Typically this phase is about gathering information specific to the work that will need to be done to make something happen. When building software, this is typically trying to understand what parts of the system will need to be touched in order to make the desired changes. This may include modification of something existing, the addition of something new, or the removal of something no longer desired. This is true for most projects, not just software. This phase is about determining what you know, and what you don't know. It may reveal questions that need to be asked or information you need to gather before being able to do the work.
There must be some analysis that is needed before work can be done. Typically this phase is about gathering information specific to the work that will need to be done to make something happen. When building software, this is typically trying to understand what parts of the system will need to be touched in order to make the desired changes. This may include modification of something existing, the addition of something new, or the removal of something no longer desired. This is true for most projects, not just software. This phase is about determining what you know, and what you don't know. It may reveal questions that need to be asked or information you need to gather before being able to do the work.
Design
Create a plan for how the work is expected to be done. A simple plan created before actually building something is an important phase of doing work. In writing projects, this could be having an outline before filling in the body of the paragraphs, or at least clarifying some key points that are planned to be addressed. For software projects, this can be a simple explanation of the components and how they'll work together. The goal in this phase is to have a plan so that you can stay focused during the build, and give yourself something to look back on as you go so you're not lost. Think of this like being able to have a map or directions to look back to as you're trying to drive somewhere, in case you get off track or lost.
Create a plan for how the work is expected to be done. A simple plan created before actually building something is an important phase of doing work. In writing projects, this could be having an outline before filling in the body of the paragraphs, or at least clarifying some key points that are planned to be addressed. For software projects, this can be a simple explanation of the components and how they'll work together. The goal in this phase is to have a plan so that you can stay focused during the build, and give yourself something to look back on as you go so you're not lost. Think of this like being able to have a map or directions to look back to as you're trying to drive somewhere, in case you get off track or lost.
Build
Make your plan a reality. In this phase, you'll begin doing whatever you planned to do. For software projects, this is where you would write the code that makes the changes you wanted, or adds the part of the feature you are working on. You may find along the way that your analysis missed something, or your design was incomplete. This is usually not a problem, and you can take steps to address the issues, and even update your analysis and design notes accordingly.
Make your plan a reality. In this phase, you'll begin doing whatever you planned to do. For software projects, this is where you would write the code that makes the changes you wanted, or adds the part of the feature you are working on. You may find along the way that your analysis missed something, or your design was incomplete. This is usually not a problem, and you can take steps to address the issues, and even update your analysis and design notes accordingly.
Test
Double-check all the cases. Usually during the build, you are constantly paying attention to the effects your changes are making. For software developers, this is known as a run-debug cycle. You make some changes, then run the app and see if your changes are working. However, this typically doesn't involve checking all the cases. You may find that you are repeating the same test scenario over and over during this development cycle because it is rapid. In a writing project, you may constantly be re-reading the paragraph your working on, but you may not be always double-checking how that paragraph fits in with the whole section. So, this is the phase where you make sure your work fits in with the whole, at some level. Make sure that the effects of your work, i.e. the changes you made, do what you expect them to, and meet the original intentions you had back in the Analyze and Design phase.
Double-check all the cases. Usually during the build, you are constantly paying attention to the effects your changes are making. For software developers, this is known as a run-debug cycle. You make some changes, then run the app and see if your changes are working. However, this typically doesn't involve checking all the cases. You may find that you are repeating the same test scenario over and over during this development cycle because it is rapid. In a writing project, you may constantly be re-reading the paragraph your working on, but you may not be always double-checking how that paragraph fits in with the whole section. So, this is the phase where you make sure your work fits in with the whole, at some level. Make sure that the effects of your work, i.e. the changes you made, do what you expect them to, and meet the original intentions you had back in the Analyze and Design phase.