Story Tracking

The stories are moved to a state of ‘In Progress’ on the Scrum board, and every day, during the stand-up meeting, individuals should give an update of how much still needs to be done for the tasks that they are responsible for to be completed. This gives the Scrum Master the opportunity to remove any impediments, and to make sure that the team is able to deliver everything that they agreed to deliver at the planning stage. There will be occasions when unforeseen issues arise, and in these situations, the Scrum Master, together with the rest of the team, will need to make a decision on whether the story needs to be resized, and either moved to the next iteration or potentially split into smaller chunks. Ultimately, over multiple cycles, this tracking of stories will allow the Scrum Master and Product Owner to understand the velocity of the team and to learn what areas to focus on in order to improve productivity.

Creating User Stories For Product Owners

The user story is a core part of Agile Software Development. Where other methods of software development have functional requirements and technical specifications, Agile has user stories. These user stories serve to explain what the product should be able to do, without specifying details. This gives the team freedom to do things in a way that is efficient and practical while ensuring that stakeholders get the product that they want.

User stories usually consist of one or two sentences explaining who it is for, the desired behavior and the reason for the requirement. The typical form is: “As a [role], I can [feature] so that [reason].” By following this form when writing user stories, the team can cover the who, what, and why about a feature. Writing good user stories helps to ensure that the team creates valuable features for the product.

But who is responsible for writing user stories? The Product Owner is in charge of prioritizing and accepting user stories, but anyone on the team can write stories. If other team members write a user story, the Product Owner can accept or reject them before they are incorporated into the product backlog. If the Product Owner allows bad user stories into the backlog, it wastes time for the team because they do not contribute value to the product. Instead, the Product Owner should only allow user stories into the backlog that are independent, negotiable, valuable, estimable, small, and testable.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: