The Scrum Task Board Explained

The scrum task board
The scrum board is the main object of interest for the entire scrum team, since each activity carried out using scrum methodology is reflected directly or indirectly on the scrum board. It is generally located in the venue where the daily scrum meetings or the daily stand ups are held before the sprint is initiated for the particular day. Scrum boards are the center point of focus for the entire team. The sprint backlog, in the form of story cards, is represented on it. Each day as the sprint progresses, the scrum board reflects the updates of work carried out by the development team. As the user stories develop, the cards are rotated on the board, and provide information to the team as to which particular activity is currently being undertaken and processed. In real time, the scrum board is updated before the sprint commences for the particular day, and it typically exhibits the sprint activity carried out the day before.   
 

Story
The story column displays the list of user stories taken up for development during the sprint. "User stories" is the work accepted by the team during the sprint planning meeting. Each user story is broken down into development tasks, and each task is individually taken up for development by the team member during the sprint.
 

To Do
The column reflects the tasks taken up for immediate development from the sprint backlog. The backlog constitutes the entire work to be completed during the tenure of the sprint – over the coming days. The stories can be picked up on a random basis, or according to a specific plan followed by the team. The “To Do” list is populated by those stories which are to be considered for development on an immediate basis, unlike the entire sprint backlog which is processed in small segments.
 

In Process
This column is populated by those tasks which are currently being developed by the programmers or developers on the particular sprinting day. Ideally, the stories included in the column should be completed on the same day before it ends. However, if the task is complex, or lengthy, the task may be extended over the next day.
 

To Verify
This column includes the stories which have been taken up for development during the sprint, but need some further clarification before they can be taken up for development purposes. Also, when a particular task is taken up for programming and if some issue is found connected with it which prevents further development, the task is transferred to the “Verify” column. The doubts or the issues connected with the story are resolved by taking help from the scrum master or the product owner, and subsequently transferred to the “Story” column or the “To Do” column depending upon the team’s decision when to develop it.
 

Done
The column includes all the tasks which have been completed by the team during the sprint activity. During the sprint review meeting, the tasks included under the “Done” column are verified by the product owner and accepted as “Done” or rejected.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

What To Consider Before Writing User Stories In Scrum So They Can Be More Effective And Meaningful

User stories in scrum
A user story is the main functional unit in scrum methodology. When any project is taken up for development using scrum, the specific requirements for that particular project is stated by creating a set or development requirements, which are termed as user stories in scrum. Usually the product owner creates the product backlog – the list of requirements needed to develop the project. The product backlog items are referred to as user stories by scrum professionals. Once the product requirement list is created, a small set of the requirements (user stories) are transferred to the sprint backlog during the sprint planning meeting for development purposes. The stories are explained to the team members in the first half of the sprint planning meeting. During the second half, team members distribute the stories after breaking them down into development tasks. A sprint backlog is prepared in this way. Subsequently, the team starts developing the functionality of the user stories during the daily sprint. In scrum, the entire project is governed on the basis of the user stories.
 

The official scrum guide does not attempt to provide a specific definition that can describe the “structure” of a particular user story. The guide actually explains what a user story is, and what part it is supposed to play in the project. It fails to provide a standard format which can explain as to how a user story should really look like. Maybe, the reason why the guide fails to provide a structural definition is because development requirements can vary from one particular project to another.  So, it becomes difficult to standardize a specific format compatible to all types of projects.  The guide, however, states that the user story should ideally be composed of three constituent parts, or include there main aspects:

1. A written description or a graphical representation of the entity which forms a part of the project
2. A detailed conversation, or an explanation which additionally describes the functionality in greater details
3. The acceptance criteria or “Done” meaning which specifies what the entity should include, how it should function, and the particular manner how it should migrate or integrate into the project

What should be considered while writing or creating user stories
While writing the user stories, certain points are important, and should be adhered to for the user stories to be effective and developmental:
 

Stakeholders should create or write the user stories
The investors and the stakeholders are funding the project for financial gains. Each project has a financial value attached to it in terms of how much the project will be worth in the market. The stakeholders know which user stories are important, and which functionality will increase the value of the project. Therefore, they are the ideal individuals to define and create the list of requirements or the user stories. The product owner carries out the work on their behalf, and represents their interests while the project is being implemented.
 

Using simple tools to represent user stories
In the manual system, stories are written down on index or story cards specially designed for scrum. The scrum index cards are very convenient to work with, and are generally pinned on the scrum board while the sprint is underway. It is important to use a tool that is small in size, so it can be easily stored and pinned on the scrum board. It should be easily readable, simple to understand, and effective. The more simple and effective the tool is, the easier it would be for the team to understand and use it.
 

Time to be allotted to the user story
Scrum advocates time bound activities. Each activity in scrum has a certain duration associated with it, and is “time boxed”. It is important not to exceed the time limit to get the most out of scrum. Each user story is allotted a certain duration within which its development should be completed. It is essential that each user story is completed in the time allotted to it since it has a certain importance value (story points) attached to it. The project turns out to be cost effective only when the right duration of time is allotted to each user story, and each story is completed in the time allotted to it. If the time limit is not allotted, the project becomes expensive and its ROI decreases.
 

Describing important non-functional aspects
Certain user stories need to be explained in further details so the team members can properly understand them. The user stories may be very important in terms of how they provide a solution for a particular end-user related requirement. They may or may not be technically complex, but it may be important for the team members to know what part the user stories are likely to play, and how much important they are as far as the overall project development is concerned. Such non-technical aspects of user stories should be explained properly so a better overview and understanding of the project related requirements is availed.  
 

Fixing the story priority
Each user story has a certain level of importance attached to it development. It is important to prioritize the user stories, so the correct time can be fixed for its development. Important user stories, or those which have more importance attached to their development, should be assigned a higher priority, and sufficient time should be allotted for completing them. On the other hand, less important stories ought to be assigned less time and priority because they do not carry much financial value with regards the functionality they offer. 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!