Read more

Story Checklist Template

Felix Eschey
March 09, 2023Software engineer at makandra GmbH

This is an story checklist I use to work on stories. For this purpose I extracted several cards related to the makandra process and ported them into a check list and refined that over time a little bit.

Illustration online protection

Rails Long Term Support

Rails LTS provides security patches for old versions of Ruby on Rails (2.3, 3.2, 4.2 and 5.2)

  • Prevents you from data breaches and liability risks
  • Upgrade at your own pace
  • Works with modern Rubies
Read more Show archive.org snapshot

This task list is divded by the Gate keeping process in the following steps:

1. Starting a new feature
2. Working on the story
3. Finishing a feature
4. After Review

Here are some tips on it's possible usage:

  • I copy the template for every new story I work on and adjust it accordingly beforehand and use it throughout the gatekeeping process.
  • This template is a rather extensive example, you might not consider everything important enough for your own checklist regarding your level of experience
  • Feel free to create your own template based on this example as an inspiration
  • I like to use Obsidian for updating the checklist because it gives me shortcuts to create, toggle and navigate checklists quite fast while being able to fold completed headings.
  • You can also consider adding the checklist for implementing design and the points from Building web applications: Beyond the happy path

The template:

1 Starting a new feature

  • Set the story to "Started" in Pivotal Tracker
  • Pull the most current master branch
  • Branch off the master with geordi branch or manually
    • Name your branch like sort-users-by-name-73624, i.e. start with the PT story id, then a shortened story description. You can also start your branch with your initials, so that everyone can see who is working on the branch, e.g. ab/73624-sort-users-by-name.
    • Make an initial commit with Pivotal Track ID and the name of the story using
      git commit --allow-empty -m <message>
      
  • Read the complete story
  • Reread the complete Issue and check if the story needs further checkpoints

2 Working on the story

To Do

  • Review Acceptance Criteria and Notes
    • Get an overview of what it should do
    • Translate it to code and browser logic

.... Checks from story ...

3 Finishing a feature

3.1 Check acceptance criteria

... I have a second Checklist to re-check everything from the story after I finish the story ...

... Possibly a second list of things I want myself to remember ...

3.2 Create the merge request

  • Within your feature branch, merge the current master and push using:
    git pull origin master  
    git push -u origin feature-branch-name  
    
    You're encouraged to use git pull --rebase if you know how it works.
  • Open a merge request by clicking the link Gitlab prints on push.
  • To open a merge request manually:
    • "Assign to" with yourself
    • "Reviewer" with your project manager
    • "Title" with a descriptive name, preferably using the story id and title from PT. Use Use gitpt or the commit bookmarklet to auto-generate the title.
    • "Description", add a link to your pivotal tracker story and Screenshots of any UI Changes
  • Set the story to "Finished" in the Pivotal Tracker

Merge Request Checklist *

  • has been reviewed by yourself beforehand
  • escapes all user input
  • does not have any log or debugging statements like console.log(...)byebug etc.
  • has green tests
  • has tests for new features
  • has been manually tested in the browser
  • has no missing translations in the UI
  • has no ugly UI changes (long content breaking out of boxes, elements without margins, etc.)
  • works with lots of records without triggering a million queries or loading the world into memory
  • sorts all lists (indexes, select dropdowns, ...) by either sorting in the database or using natural_sort in Ruby
  • paginates long index lists
  • has all necessary database indexes to speed up foreign key look ups and commonly used queries
  • if it adds any migrations, takes care of existing records
  • if it makes major changes, has updated the README as appropriate

4 After Review

4.1 If your code does not pass review

  • Make sure that every comment is checked when you are 100% that it is done
    • Do it, check after it is done
  • Run your new specs and features again
  • Review Acceptance Criteria and Notes
    • Make sure everything necessary is done

4.2 If your code passes review **

Your project manager will either merge and deploy the changes, or he will ask you to do it yourself in a note to the merge request (you will receive an e- mail)

If you're supposed to merge yourself, you need to

  • Run all tests again by using geordi t
  • Get the latest master
  • Squash your commits using git rebase - i master or something similar
  • Merge into master
    git checkout master  
    git merge feature-branch-name  
    
  • Push
  • Delete the feature branch with
    git branch -D feature-branch-name  
    git push origin :feature-branch-name  
    
  • Deploy to staging
  • Set the corresponding PT story to “delivered”
  • Close the merge request on GitLab (happens automatically when you merge or delete the remote branch)

Also see:

Felix Eschey
March 09, 2023Software engineer at makandra GmbH
Posted by Felix Eschey to makandra dev (2023-03-09 10:11)