Confirmed users
1,193
edits
| Line 29: | Line 29: | ||
Tasks in the Sprint Backlog can sometimes become very broad. To avoid this, the team breaks tasks down to be as small as is reasonable. For example, a task for implementing user login might be broken further into tasks like "Design interface for user login" and "Talk to Tim about how he implemented user login". Doing this makes work less intimidating and helps the team track its progress at a more granular level. | Tasks in the Sprint Backlog can sometimes become very broad. To avoid this, the team breaks tasks down to be as small as is reasonable. For example, a task for implementing user login might be broken further into tasks like "Design interface for user login" and "Talk to Tim about how he implemented user login". Doing this makes work less intimidating and helps the team track its progress at a more granular level. | ||
The team | The team uses research tasks whenever possible. For example, when starting the user login feature, the team might create a task like "Research: What services can we use to power login?". The team discusses the question and shares decisions in an associated Bugzilla bug. | ||
Sometimes, the team needs to coordinate with IT to implement a feature. When this happens, the feature is broken down by responsibility, with at least one task for the team to complete and at least one task for IT to complete. The tasks are written to be independent, allowing the team to mark its tasks as complete even regardless of the progress being made by IT. | |||
If there is more than one front-end task, the team uses Django Waffle flags during implementation to ensure that the front-end is not accessible until all of the tasks are complete. When all of the front-end tasks have been implemented, the Waffle flag is enabled to make the entire front-end available. Waffle flags can also be used to make incomplete parts of the front-end available to special users for testing. | The team pays special attention to breaking work down when a feature goes a long time without being merged into the MDN source code repository. When this happens, the work is broken down into one or more back-end tasks and one or more front-end tasks. As back-end tasks are implemented, they are merged without the corresponding front-end tasks. If there is more than one front-end task, the team uses Django Waffle flags during implementation to ensure that the front-end is not accessible until all of the tasks are complete. When all of the front-end tasks have been implemented, the Waffle flag is enabled to make the entire front-end available. Waffle flags can also be used to make incomplete parts of the front-end available to special users for testing. | ||
=== Sprint Burndown Charts === | === Sprint Burndown Charts === | ||