SW project management

Highly based on 'Scrum' methodology, but a bit modified.

Epic: A unit of job
  • Epic should be committed within a single PSI(Potentially Shippable Increments)
    • PSI(Potentially Shippable Increments): A time box that a team uses for the achieve a certain business goal or goals.
  • Length of PSI can vary, but it's usually 6~8 weeks.
  • A PRD(Product Requirements Documents) should be created for each epic in Confluence
  • Epic Ticket should be also created in Jira
  • it appears as a single branch: e.g. feature/add_search
Story: A sub-job of an Epic
  • Story should be done within less than a sprint
    • a few Stories would be done in a single sprint
    • if some task is too big to be done in a single sprint, you can horizontally divide the story
      • usually happens if the story has a lot of acceptance criteria
      • horizontally dividing means that each story should be applicable independently
      • e.g. you want to make the map app to show restaurants near the user in order of ratings
        • you can it divide into 'view nearby restaurants' and 'order by ratings'
  • Length of sprint can vary, but it's usually 1~4 weeks.
  • Story Ticket should be created under the Epic in Jira
  • A User Story / Acceptance criteria should be allocated for each Stories
    • should be written in the ticket
    • User Story should be written in a format of "As (user), I want __, so that __"
    • Acceptance Criteria should be written in a format of "Given/When __,  that __"
  • It would be also great if UX Flow diagram or Design is allocated for each Stories.
    • should be linked in the ticket
  • it appears as a single sub-branch of the Epic's branch: e.g. feature/add_search/search_db

Sub-Task: A sub-job of a Story
  • Sub-Task Ticket should be created under the Story in Jira
  • Sub-Task is created and allocated by developers not a Product Manager.
  • It is primarily for the developers' communication and collaboration
  • But it still has to be moderately small, so that PM can notice the stories' progress
  • it appears as a single sub-branch of the Story's sub-branch: e.g. feature/add_search/search_db/db_creation

  • As a developer, 'a ticker per a commit' is very reasonable


Above is a great example for the Story ticket.
  • Some teams include User Stories, Acceptance Criteria, and design docs in PRDs, not a Story ticket
  • It is not a good practice because developers mostly sees only the Design and barely sees PRDs. So they might not keep up with the requirements change.

댓글

이 블로그의 인기 게시물

Interface of Java

Data Analytics Overview(OLTP vs OLAP)

Leetcode