The “King/Servant” pattern is one of the most important patterns to bring to your team. Looking down the taskboard for the sprint the team members are likely to either pick “easy wins” or those user stories which they have a special interest in getting done. That it, of course, only if we deal with a relatively new team or new team members with less Scrum training is brought on to the team.
The King/Servant pattern will ensure – if practiced – that those tasks worked on are in fact the tasks with the highest business value (prioritized by the Product Owner). In the event that something happens so that the sprint is not completed (and tasks is not done) the King/Servant pattern ensures that the most important tasks are completed.
People are often asking me how this will work in practice. This is mainly in concerns of the QA phase where QA will test the tasks that the team has completed. Do the team sit idle while while QA work? No, of course not… The team works spend the most sensible amount on the top prioritized user story and when it’s completed and is ready for test, the team moves on to the second highest priority (and so forth). The QA starts testing the issue (based on priorities) and report bugs. When the bugs are reported the team stops working on the sprint tasks and return to the “king” story. This goes on throughout the sprint so it’s basically a mixture of developement- and bug fixing.
Depending on how versatile your team is this pattern will give you some great results in terms of getting the most important stories ready in time for review. However, not all teams are so versatile and cross functional so that may pose as a problem for them to incorporate this pattern. But based on the framework of Scrum the idea is to create a team which are in fact cross functional and hence the pattern will be one more step closer to completing the highest priority stories done.