Tools And Frameworks

>

Managing-user-stories

Getting Started

PM Roles and Responsibilities

Communication

1-on-1 Guide Conflict Resolution Developer and Designer Communication

Tools and Frameworks

GitHub - Best Practices for Commits and Branches JIRA, Kanban Boards, and Agile Methodologies Managing User Stories

Wrap Up

Project Wrap Up

Managing User Stories

Overview

Why is the process of creating user stories so important?

Creating concise, easy-to-understand user stories is vital to the agile software lifecycle - without doing so, you risk software developers spending too long on a task, getting confused, or doing too much or too little in relation to the task’s true expectations.

Breaking Down User Stories

The Gherkin Method

Key Takeaways:

  • The Gherkin Method is a structured approach to writing user stories - it enforces Behavior Driven Development (BDD). While we don’t use this concept directly in CodeLab, it makes designing our stories much easier.
  • To use the Gherkin Method, the body of the story should simply follow the structure of “Given X, When Y, Then Z”.
  • This allows us to write our story’s description for developers and its acceptance criteria all in one go.

Focusing Stories on One Task

Key Takeaways:

  • When we create user stories, they shouldn’t have multiple pieces of functionality lumped into themselves.
  • Thus, each story should have one clearly defined small task - a user story should never take more than a week to complete, and ideally should take even less time for a singular developer.
  • Each story should also have an hour estimate built into its title as well using story points - if a story’s point value is > 5, it’s probably too big of a story.
    • Make sure to take everything into account for the story when estimating it’s point total - including research and code clean-up time.

Assigning Stories

While this was briefly mentioned in one of our previous videos, we’re clarifying it again here.

  • Every team is different - consult with your team first before assigning stories each week, and try to pick up on what people like to work on. Try to let people work on what they enjoy the most.
    • With that said, it’s important we don’t only have one source of knowledge on a particular topic - still make sure that people are rotating between different types of tasks.
  • Make sure that your stories with the highest priority are at the very top of the “Get Next” pile at the start of each week, with blockers kept in mind when forming that order.
  • At each sprint meeting, have developers estimate how many hours they have for the week, and then pick up all of their stories for the week using the assignment methods just described above. Use the story points as a way to fill up each developer’s availabilities for that week. Developers can pick up more stories after consulting with you if they have more time in the week than expected.