Planning User Stories with Agile

When the Plan Fails :

1. Add more money
2. Abandon the project

Increasing predictability :

1. Establish a deadline, not a detailed plan
2. Commit to incremental, small deliveries that work.

Iterations(Sprint in Scrum)

Deliverable are created. User Request

Agile is more flexible than waterfall. Waterfall results are only visible at the end.

Plan with estimates

Cone of Uncertainty describes challenge

Agile helps decrease the size of the errors, for each estimates, by reducing the size of the requirement for each sprint.

Product User roles : A bundle of user experiences.

Product Manager comes up with the user roles. 3Cs : Context, Character, Criteria

User Story is a brief statement of a functional product need from the perspective of a specific type of user.

User Story Format :

As a (user role), I (want/need/can) (goal) so that (reason).

As a standard customer, I want to see a list of benefits of upgrading so that I can ee if it;s worth the cost.

From XP, 3Cs are : Card, Conversation, Confirmation

Card is a 3x5 index card mentioning the user story

Conversation occurs for the card, to ensure development team knows how to develop

Confirmation is required for noting what 'done' is for each development team and is usually written behind the card.

Evaluating user story :

I.N.V.E.S.T.

I : Independent
N : Negotiable(Problem with high tech knowledge in product managers)
V : Value
E : Estimable
S : Small(1-2 week development)
T : Testable

Epic : A large value statement. Large grouping of work with common objectives

Epic Splitting : F.E.E.D.B.A.C.K.

F : Flow(how the product is to be delivered)
E : Effort(based on developer's effort divide)
E : Entry(how customer enters the data)
D : Data Operations-Influenced Story(Ex : Editable list for easy operations on data)
B : Business Rules-Influenced Story(Complex value in epic)
A : Alternatives Criteria(Ex : GPS to Zipcode for location tracing)
C : Complexity-Influenced
K : Knowledge

Agile Charter : Agreement from each team member. It should be 1 page or less. Should mention :

1. Vision(Functional brief description for the original idea)
2. Mission
3. Success Criteria

Example : Vision : Help people enjoy the outdoors and learn more about the wonderful birds that live on our planet. Mission : Creating a cutting-edge tech platform that combines a website a smartphone app, and location awareness to help our customers identify local birds. Success Criteria : Sign up 10,00 users within 3 months of initial, 100,000 by 1 year, get endorsed by major ornithology website

Charter Success Criteria != Functional Success

Relative Sizing : Method for predicting task effort by comparison or grouping tasks of similar difficulty.(Used for Agile estimation)

Benefits :

1. Removes false comfort of 'preciseness'
2. Clarifies estimates vs Commitments(Estimate is best guess, commitment is worst case scenario)

Planning poker : Individual estimate for each story point Groupthink : Tendency of group members to privelege consensus over debare by agreeing with the most popular opinions

Planning poker eliminates group think. Team should reach a consensus for the effort. Debate is required between highest and lowest estimators.

Ideal Agile Project Characteristics

1. Rigorous but consistent pace
2. Predictable and practical workday
3. Data-driven pacing

Velocity for each sprint, is estimated based on how many story points get assigned. External influence brings down productivity.

Sprint Planning Options :

1. Sprint Backlog
2. Taskboard

Story Volume:

1. Story Intuition
2. Velocity of the team

Takes 2 weeks to have a sustainable velocity.

Rough Order of Value(ROV) : Planned grouping of epics that can be delivered over time.

Common Pitfalls

Agile Principle 1 : ...satisfy the customer through early and continuous delivery of valuabe software Agile Principle 7 : Working software is the primary measure of progress

Avoiding Excessive Documentation

1. Document continuously
2. Collaborative documentation
3. Be driven by project continuation

Scrum Master prevents too much creativity to prevent over-engineering.

Agile framework changes should be considered after having a well developed framework. (i.e. do not mix roles at start of project)