user story refinement in project gate

User Story Refinement in Project GATE

Spirit Tu

22nd January, 2015

About me

• 12-year NTUT life

– 2004, B.E. degree in EN from NTUT

– 2006, M.S. degree in CSIE from NTUT

– 2012, Ph.D. degree in CSIE from NTUT

• Senior Program Analyst at GSS

– Oct 2012 – May 2013

• Senior Software Engineer at Gamania

– iOS, Android, and PC (?) App developer of the project GATE

User Story Refinement in Project GATE2

Project GATE?

• According the NDA, Project GATE is

– A cross platform (iOS and Android) app with gamification, cloud services, and social network

• GATE?

–ゲッターロボ

– Getter Robo


Sprint timetable

• 2 weeks / sprint

– Daily scrum held on 11:45 – 12:00

• For a better user’s experience

– Polish & tuning (debugging)

• Publish a version on Mon if nothing wrong

4

Mon Tue Wed Thu Fri

Planning Refinement

Planning Refinement

Mon The Wed Thu Fri

Tuning Review

Polish Tuning Retrospective

Week 1

Week 2

User Story Refinement in Project GATE

Feature design team

(kanban)

Source of user stories


User story

refinemen

t

Product Owner Scrum Master Team Member

Artist

Team Member

Programmer

User story refinement 1.0

• Feature design team transform the PO’s (boss) vision into features

– Specification document


x 47


• To estimate the story point

– Requirement understanding

• Ensure feasibility and possible solution

• Check details and questions

• QE make up test cases

• Screen elements

– Rough architecture design & API discussion

• Data structure



• Issues should be solved

– Split stories based on screens

• Not end-to-end stories

• Duplicated or similar stories

– Split stories based on module

• Heavy dependency between stories

• Implicit value


First impact

• In the retrospective meeting, team members argue the bad stories

– Value driven

– Must be end-to-end



• Everything will go right?

– Yes, the user stories have explicit value, but…

• Huge user stories


This is a user

story!


• Team members split the user stories

– Time-consuming meeting

• Ensure the size of each story for art, client, and server

– PO has to trace the completeness between the stories and the specification documents

• Ensure everything in specification storied

– Feature design team need revise the specification documents many times

• A feature may need refinement twice or more



• However, there are still some advantages

– End-to-end

• Easy to demonstrate in the review meeting

– Well-sized user stories

• More precise task time estimation

• Stable velocity


Second impact

• Again, in the retrospective meeting, team members argue the need of a completespecification document

– Live document?


Flow chat based refinement (1/3)

• Phase I – Introduce the screen flow chat



Artist

Team Member

Programmer


• Phase II – Split the user stories


Product Owner Team Member

Programmer


• Phase III – Story point estimation



Artist

Team Member

Programmer

Story 1: 8 + 2 + 5 = 15

Story 2: 5 + 0 + 2 = 7

Story 3: 5 + 8 + 1 = 14

Story 4: 3 + 0 + 0.5 = 3.5

Story 1: 2 + 1 + 0.5 = 3.5


• Team member split the user stories based on the screen flow chat

– End-to-end and able to demonstrate

– Explicit value (maybe small)

– Feature design team adds details in the stories

– Average story point: 8.9

• However, the stories split by this method are frozen

– Boss wants a more quick responsive time


Responsive time not quick enough?


Responsive time

• Find the lead time from the past records

• In the retrospective meeting, team member try to meets the boss’s requirement

– Two feature design teams


Feature 1 design

A team

Feature 1 develop

A team

Feature 2 design

B team

Feature 2 develop

B team

11.4 days 20.1 days 11.1 days 19.8 days

Cycle time Cycle time

Runway lead time Scrum develop lead time

???


• Two feature design teams

– Design the feature based on the boss’s vision and minimum requirement

• A simple architect after the feasibility study

• A screen flow chat or a description

• User stories with story point estimation


Feature 1 design

A team

Feature 1 design

B team

Selected

Design

Develop

Feature 2

Feature 2 design

A team

Feature 2 design

B team

Selected

Design

Develop

Feature 2

60 % - 70%

30% - 40 %

Pretty quick responsive time?

• Completed two features by this method

– Pros

• 2 sprints for a feature 1 month for a feature

• Reduce document overhead (revise)

• Team member fully participated in feature design

– Cons

• Work overtime

• Too many context switch

• BCD (boss centered design) annoys some team member


How about internal user stories?

• Internal user stories (e.g., performance tuning, refactoring, etc.) usually arranged in planning meeting by team member, but

– Each function has different issues to be solved

– Some issues need cross-function cooperation

– Some issues need PO’s decision, e.g., security policy

• Long planning meeting


User story refinement technical branch

• At the end of the retrospective meeting

– Team member book issues that need refinement

• Issue

• Cross function requirement

– PO arrange refinement meetings

• Prioritize issues and schedule the meetings

• Decide the participants


A growing team 15 members at May 2013


1

3

2

12

3

1

11

Android

iOS

Server

QE

Art

PO

Planner/UX

Scrum Master

Secretary

A growing team 24 members at Jun 2015


4.5

3.5

3

3

3

3

2

1 1Android

iOS

Server

QE

Art

PO

Planner/UX

Scrum Master

Secretary

User story refinement 5.0 beta

• Communication cost

– O(n2)

– Too many opinion to make a decision

• Extended feature design team

– At least, one representative for each function

– Refine the rough design

– Split the user stories

– Estimate the user story points


Extended feature design team


User story

refinemen

t

Product Owner

Team Member

Artist/UXTeam Member

Programmer

Extended

Feature design

team

Summary

• User story refinement meeting is important to Startup

– Team members feel that they are building an amazing product, not just a work (well, it’s still the boss’s product)

– Team members’ participation can provide good quality user stories

• Continuous improvement

– User story refinement meeting should also be improved based on the feedback


Well, something updated

• Prototype design team

– Develop prototype on the branch

– Minimize the design team member

• Other team member can still provide suggestions to the prototype design team

– Hackpad

• Progress update

• Suggestions and comments

– More quick response?


user story refinement in project gate

Software

project gate1040

project gate2project

project gate8first impactin

project gate6 x

project gatespirit tu22nd

project gate13 flow

team members

solvedsplit stories