The Agile Product Backlog
A 59 Seconds Agile Training Video
This is an Agile Product Backlog training video.
Continue to Part 6 Below
The Agile Product Backlog
A 59 Seconds Agile Article
This article provides an ‘Introduction to the The Agile Product Backlog‘ and looks to discuss what the backlog is and what role it plays within Agile projects.
Prioritising the Product Backlog
One of the most popular techniques used to prioritise the product backlog is MoSCoW. It is an intellectual property of the Dynamic Software Development Method, however many scrum teams use it to priorities their user stories. The MoSCoW acronym stands for:
M is for must have:
These are the user stories that must be included before the launch of a product. That is, at the beginning of a project these stories should be clarified and prioritised. Not delivering these stories means that the solution is not viable or incomplete. These stories define the minimum scope of the product based on the priority of the customer.
S is for should have:
These user stories are not critical to the launch of a product, but are considered to have high value to the customer. However if these stories are not delivered the customer will still get value from the product.
C is for Could have:
These user stories are nice to have and can be included without too much effort or cost. However these stories will be the first to be removed from the scope of the product if the deadlines of the project are at risk.
W is for Won’t have:
These user stories have been requested by the customer but are not the part of the scope but may be included in a future phase of development. It is important to understand that MoSCoW prioritisation is specifically designed to be implemented within fixed time frames. If the backlog is not designed based on fixed time frames, the customer will most likely define everything in the backlog as ‘must have’.
The best way to think about MoSCoW prioritisation is:
“Within this specific time frame I must have, should have, could have, or wont have this feature.”
Sometimes MoSCoW fails when the stories are defined at a very granular level, as this will lead the customer to again perceive all stories, as ‘must haves’. For example an e-commerce system must have a payment module but there are opportunities to prioritise the story based on type of payment, rigour, security and so depending on the payment method used.
Continue Reading —> Next
The Agile Product Backlog
A 59 Seconds Agile Video Animation
Continue Reading —> Next
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Continue Reading —> Next
The Agile Principles
A 59 Seconds Agile Infographic
Continue Reading —> Next
Agile Scrum Master Training Course
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Continue Reading —> Next
