What is Sprint Task Board

What is a Sprint Task Board?

A sprint task box is a time box. Each sprint has a start and end date during which a set of selected user stories have to be completed and confirmed. The following image shows you the key elements of a sprint, which includes a set of user stories, the scrum members involved, the assignment of work, the duration and end date (top-right corner).

At the beginning of a sprint, the product owner, the stakeholders and the development team meet together to prioritize, and then select the user stories to be accomplished in the sprint. Since different parties have different preferences, considerations and concerns in regard to the project and project schedule, the purpose of meeting is to provide different participants with the opportunity to listen to and understand others’ views, and to come up with a set of user stories that is agreed by all parties.

Sprint duration

Fast delivery of quality work is one the reasons why software teams want to adopt agile software methodologies. Thus, although there is no one-size-fit-all choice for sprint duration, it’s commonly agreed that the duration should be as short as possible. But how short should it be?

While a long sprint length is not preferred, an unreasonably short length of a sprint may weaken the development team’s motivation in completing significant work, or may even lead to a poor quality of deliverables.

So, the selection of sprint duration is the result of discussion among the whole team – product owner, scrum master and scrum members like database designers, programmers, UX designers, testers, analysts, etc. But in the end, someone has to make a decision. At that moment, the scrum master is usually the one who will gives the answer.

Traditionally, a sprint last for a three weeks to one month, but nowadays more and more teams have been successful with two-week sprints. After all, there is still no fixed selection to sprint duration. A good scrum master has the collaborative and facilitative skills in determining the sprint length, for securing works to be accomplished as expected. Here are some factors that a scrum master may consider:

1. Agreed project schedule
2. Availability of customers/stakeholders/product owner (Who can clarify potential doubts)
3. Working culture of customers
4. Capability of scrum team
5. Scrum experience

Once the team has reached a consensus, all future sprints would follow the same sprint duration without frequently changing it sprint after sprint. Yet, it is a good practice for the scrum team to keep reviewing the effectiveness of sprint, and to find out an optimal sprint duration that work best for everyone.

Confirmation of Works (User Stories) in Sprint

The development activities are setting up around the user stories after a sprint begins, and more and more user stories are implemented as the sprint progressed. Yet, the complete implementation of a user story is not the end of the story. There is still an important step to be gone through – confirmation.

To confirm a user story is to try out the implemented feature and decide if the feature is implemented as expected. The judgment should be made solely based on the criteria established when detailing the user stories, written in the form of confirmation items. During confirmation, product owner is given a testing environment or device for testing the implemented work. The product owner will walk through the confirmation items written on the user story one by one. If all the items are confirmed to be done, the user story is said to be confirmed. If any item is found undone or not work as expected, the product owner will request the development team for a fix. The fix and confirmation processes will repeat until the user story is fully confirmed.

When to Confirm?

Sprint, and in fact agile is a continuous delivery process. Instead of confirming the user stories at the end of a sprint, confirmation should be done right after the completion of any user story. However, if the product owner failed to participate in continuous confirmation, you may arrange weekly meetings that last for 1 to 2 hour each. During the meeting the product owner will work with the team in confirming the completed user stories. The meeting also involves a discussion session that clarifies the doubts found when implementing the other stories included in sprint.

Confirmation is not equivalent to testing

As said, the purpose of confirmation is to make sure the user story is implemented properly. The judgment is based on the items established as confirmation items during the detailing of a user story, no more and no less. The scale of checking is far from enough for ensuring that the feature is ready for production use. So, when to perform a ‘real test’?

Different teams have different practices in regard to software testing. Some teams prefer a per-sprint test which involves the conduction of tests like integration test and regression test by the end of a sprint. Some teams prefer setting up a stabilization sprint for, as its name says, testing and bug fixing. No new development activities will be done in that sprint.

No matter which approach you choose, keep in mind that the choice is not any-one’s choice but everyone.

Visual Paradigm provides all the tools you need in agile software development, which includes UML Use Case Diagram tool, (agile) user story, sprint, storyboard and wireframes for UX design, task management tool, etc.