No Questions

Our last article was devoted to the processing of bugs. This article is the last in the Perfect Development series.

The last three rules are:

  • Developers update Task ETAs daily, and at a minimum, once shortly before the Daily Scrum.*
  • Developers update Task statuses immediately when they change.
  • The Product Owner returns User Stories that failed the Product Owner Review into the Sprint Backlog and must provide a reason and description of why the User Story failed.*

 

Developers update Task ETAs daily, and at a minimum, once shortly before the Daily Scrum.*

To refresh our memories from previous articles, Task estimates are not pledges of anything. They are just the best estimate at that moment in time of how many hours the Developer thinks are still needed to finish the Task. It's not that if I start working on a three-hour Task, it will definitely get done in three hours. I'm just saying that I think I'll have to work on this Task for three hours to finish it.

And on this point, to keep track of our progress during the Sprint, we can use a Burndown chart. To use it, we need Tasks to be updated at least once shortly before the Daily Scrum so we have the most relevant information during the Scrum.

 

Developers update Task statuses immediately when they change.

Tasks have only three states: Backlog, In Progress and Done. When there is no work performed, the Task is in the Backlog state. When a Developer starts working on the Task, they should move the Task to the In Progress state, and when they complete the Task, it should be in the Done state.

To some, this may seem like a lot of administration. But, when team members cooperate and work together, they can see what is going on without the need to ask and disturb others. It seems strange, but isn't that the thing we're trying to eliminate? To not distract Developers from their work during the Sprint?

The transparency we want to achieve by this is based on giving all the information—even information we don't know will be used—because we don't want to decide if it will be used. Simply, if somebody needs it, let them take it.

 

The Product Owner returns User Stories that failed the Product Owner Review into the Sprint Backlog and must provide a reason and description of why the User Story failed.*

One of the rules in the minimum definition of Definition of Done in ScrumOne is that when something is considered Done, it should also be reviewed by the Product Owner. This means that the User Story meets the acceptance criteria that are defined within it. It also helps Product Owners have an overview of what was completed throughout the Sprint, prepare for the Sprint Review and communicate more easily with Stakeholders.

If the User Story doesn’t meet the necessary requirements, the Product Owner will return it back into the Sprint Backlog. Providing a good reason helps the Developers see what needs to be fixed or changed right away without needing further clarification, thus making the resolution of the issue easier, faster and smoother.

 

This article concludes our chapter dedicated to Perfect Development, but it doesn't mean that we have nothing more to say. We are looking forward to being able to introduce other interesting topics to you in articles to come.

Thank you for reading!