Skip to content

Latest commit

 

History

History
96 lines (70 loc) · 4.75 KB

02-storytime.md

File metadata and controls

96 lines (70 loc) · 4.75 KB
Raw

Remember

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Getting Started

  • Before we start, assign a "product owner" and a "scrum master" in your group.
  • Take a few moments to brainstorm a list of stakeholders (team-member, professor, reader of your website) and write them down.

Setting up GitHub project boards

  • The product owner should create a new GitHub repository where your group project will live (initialize it with a README file). There will only be one repository for the group project and it will live in the product owner's GitHub account.
  • In the "Projects" tab:
    • create a project called "Backlog" (don't use a template), and put two columns in that project "Personas" and "User Stories".
  • In the "Issues" tab:
    • under "Labels"
      • Open up the "labels" and delete all the existing labels
      • Create a new label called "User Story"
    • under "Milestones"
      • create two milestones: SPRINT 1 and SPRINT 2

StoryTime Meeting

Here is an example projoect backlog: - https://github.com/code4policy/project/projects/2

Part 1 - Write User Stories

Talk among your group and start capturing user stories for your project. Its okay if they seem beyond the scope of what you think is possible in two one-week sprints. Create as many stories as you need to capture what you know about user needs so far, I anticipate you'll end up with at least 10 or so stories, maybe more. You may not ultimately get to building some of these and that's alright. This is an exercise in understanding the users needs, and envisioning what the product could be. Remember, a story is not a contract, it is an invitation to a discussion.

These should be real user-stories that help guide your actual project, not hypothetical ones. They should define what you and your teammates hope to build, so be honest about who your users are. During this first stage your stories don't have to be super refined, we will think more about INVEST and the definitions of done in the next part. Take each discrete story and put it in a note in the "User Stories" column of your "backlog" project board.

Here are some examples:

As a design student applying for jobs

I want a website that looks good

So that I can use it in my portfolio

--

As a reader

I want a website that tells a clear story

So that I can come away with a better understanding of climate change

--

As a group that is working remotely

I want a site with one discrete page and dataset per group member

So that it is less difficult to coordinate if we're all working on separate pages.

--

As a student who cares about my GPA

I want to make sure the requirements for the project are met and documented

So that nothing gets left out and we get a good grade in the class.

--

As a creator of an online visualization

I want to be properly attributed

So that I don't feel that someone else is taking credit for my work.

Part 2 - Organize and Refine User Stories

  1. As a team, organize your stories from smallest to largest.

  2. Story Sizing

    • combine stories that are the same
    • remove stories that have no value
    • split stories that are too big and place each part back into the stack

  3. Story Splitting - the "small" end of your list is where the stories you'll likely start on in Sprint 1 will be. If you have things that seem immediate but are on the "large" end, you may need to split those stories up.

    -SCRUM: A Breathtakingly Breif and Agile Introduction

    Remember, the stories should capture user needs. You don't have to make them too granular since stories will eventually get broken down into tasks.

  4. Select the most immediate user stories (probably ones on the smaller end of your list at this point), and convert each one to an "issue". Make sure they meet I-N-V-E-S-T and have a strong definition of done. You only have to do this for a handful of well-defined issues at the top of your stack, not for the ill defined ones at the bottom of the stack. You can deal with those during your next storytime meeting.

    1. convert the "note" to an "issue" (you can hit the ... at the top right side of the card)
    2. use a checklist to make sure they meet I-N-V-E-S-T
    3. add one or more definitions of done (this can be text or a checklist)