FAQ | How to prioritize Scrum backlog in ZenTao?

Questions

Some users believe that the Sprint Backlog has no order.  So should priority be listed in the task list of a Sprint in ZenTao?

Analysis

There is one list of Stories that are pending for a Product Backlog. It is completely ordered right now with ZenTao Scrum project management tool when a Story is created it gets a Priority, 1-4. That places it in order but there can be multiple Stories at one Priority. Each Story stays at the position, Priority unless changed manually. In the Product Backlog, a Story would be placed initially at the end of the list. When another is created would be placed after that one. The Product Owner (and only the Product Owner) can at any time move any Story up or down to a new position in the Backlog, any where from the first down to the last. 

At the Sprint Planning meeting, the team takes the first item out the Product Backlog,  moving it into the Sprint Backlog. They decide if they also can complete the next (new top of) the Product Backlog, If so they move it to the Sprint Backlog. They repeat this until they, the team decides, that they will not be able to do any more Stories. This then becomes the Sprint Backlog.

No Priorities. The team commits to completing these Stories by the end of the Sprint. So, there is no Priority field for Stories. When a Story is in the Product Backlog it has a position in the list. Changeable only by the Product Owner. When the Story is in the Sprint Backlog it has neither a position nor a Priority.

All of the Stories in the current Sprint will be completed before the end of the Sprint. The team decides how many of the top Stories in the Product Backlog to accept at  the start of the Sprint. They adjust/improve their ability to make wise decisions on this over time. They work with the Product Owner over time to make smaller more specific Stories to give a finer grain of control . The individual Stories are not the release point for the team. The Sprint completion is the release. The result of the Sprint is to be release-to-the-customer ready.

 
These details matter in Scrum. They completely change the dynamics of the workspace. No longer can some salesman walk into the developer's office and put pressure on them to  work on something different. That salesman's only path to manipulate the process is to go to the Product Owner, the only one who can change the order of Story work. Also, in the Sprint the team members select the specific Story that they will work on, not some manager. This gives more buy-in by the developer. The team can plan their work during the Sprint without the constant changes that every place I have ever worked introduces. It is a much more pleasant environment. It reduces stress.  It reduces conflict. Expectations are clear for the developers, management, the rest of the company & customers. The company can make as much of the details of the process visible to those outside the team as they choose.

Putting Priorities on stories in a Sprint has negative effects. One lets someone outside of the team micro-manage which introduces more requires for no benefit. Two it implies that Stories are the release point rather than the Sprint. This also changes the dynamics of the process adding more requirements to no advantage. These are just means to get around the Scrum process.
 
If the release cycle of the Sprint is too long, thus prompting the desire to get a Story out earlier, that indicates that other problems exist. If there is just some random Story that is this issue, don't ruin the whole process because of it. If it is an ongoing issue then reduce the length of the Sprint. This is an indication of a bulky process. Become more agile and get the release cycle shorter. 
 
It is natural for those who are used to other development processes to find this lack of control within the Sprint too sloppy.  Out of context it is hard to see that it does work. The team members will get the job done. Trust them. Go away and let them do their job. Go make sure they have the resources they need. Provide better input for the Product Owner so that they can make better choices in ordering the Product Backlog. This system really does work.
 
If the organization has a pressing need for a fix use a Patch Process outside of the development/release process. Then for the future work to improve the quality of changes to the product before they are released.

Scrum gives:
- The Product Owner complete control over the work items & sequence. All input interference comes to/through the PO.
- And even the Product Owner does not disrupt the team during a Sprint. There is no flipping of priorities on the team because the only time the priority matters is at the Sprint Planning meeting.
- The team is in a safe protected working environment free from the normal distractions and constant interruptions of workflow made by changing priorities.

Answer

In ZenTao, you can customize whether you want Priority to be seen in the task list. Go to Sprint->Task and click the button to customize the column. Uncheck the P, meaning Priority in ZenTao, then you will not be able to see the task priority in ZenTao.