Agile Class Week 5: User Stories


The first principle of agile is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” How can the team know if the results are satisfying? They use User Stories. 

This week, I read chapter 5 of the book "Learning Agile" which talked about the practices that are used for planning sprints. It also explained how user stories can be beneficial in understanding what users need from the software.

User stories are used to capture product requirements of functionality. The product owner is the one responsible to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Everyone on the team participates with the goal of creating a product backlog that fully describes the functionality to be added over the course of the project.These stories are intended to be short descriptions of a specific way that a user will use the software. They typically follow a simple template: As a <role>, I want < goal> so that <benefit>.

User stories are needed in planning so that each can be given an estimate of how difficult or time–consuming it will be to develop. An abstract measure of effort required to implement a user story is called a story point. Last week, we had a sprint planning and we used the Fibonacci sequence to assign a point value to each story for our card game "Reality Clash".

I was assigned to create a hero deck and the estimation I gave for Doubt is 1, Effort is 8, and Complexity is 8. This week, I am not really an expert in game development, but one of the assigned Scrum Masters was able to help me. That's why I was able to finish the deck I was working on and then helped another developer. After that, the scrum masters were asked to create a burndown chart so the we could see how the sprint is progressing in comparison to the past velocity, the points for all fully completed user stories.

Source(s):

Comments