“The best way to get a messed up project is to start earlier than the basic requirements have been defined” - Mario Fusco.
Scrum
Roles
Product owner:
- Customer voice; represents the customer
- Translates user/customer demands into user stories
- Maintains and prioritizes the backlog
- Negotiates timing and content of releases with the team
Scrum master:
- Coach: facilitates the work and acts as the process leader
- Facilitates communication within and outside the team
- Represents management, but protects the team
Team:
- Everyone is a developer; no hierarchy
- Self-organizing and cross-functional
- Collective responsibility for achievements
Product Backlog Items
Epic:
- Large piece of work that may span multiple sprints
- Abstractly defined, high-level requirements
- Must be broken down into stories
Story:
- Small, well-defined piece of work with concrete and extensively defined acceptance criteria
- Must be handled in a single sprint
Task:
- Concrete and time-boxed piece of work
- May have subtasks
- Assigned to one or a pair of programmers
Product vs Sprint Backlog
Product backlog:
- Everything that must be done
- Prioritized and maintained
- Not all items have estimates
Sprint backlog:
- Items that will be handled in this sprint
- Fixed for the sprint; items shouldn’t usually be added or removed
- Only high-priority items may modify the current sprint
- All items have estimates
Scrum Board
All items should be in one of the following columns:
- Product backlog
- Sprint backlog
- In progress
- Review
- Done
Snow ploughing:
- Start the sprint with the highest priority items
- Group related items (e.g. same story) together; reduces cost of context-switching
Users
Personas
Can’t think in terms of some generic user:
- Hard to extract clear requirements
- Hard to identify added value
Personas:
- Fictitious people with fictitious details
- Characteristics (skills, environments, goals) related to the system
- User archetypes synthesized from common attributes
- Clear behavior patterns and goals
Keep the number of personas limited.
User Profiles (Actors)
Focusing on classes of users. Classes can be defined by the users’:
- Physical (e.g. disabilities)
- Cognitive (e.g. disabilities/motivations)
- Relevant social/ethnic/religious specificities
- Educational background
- Task experience
Comparison
Profiles and personas should be defined by user interviews, not imagination.
Personas focus more on what their motivations while profiles focus more on who they are
User Stories
- One goal; one interaction
- Natural language
- One set of acceptance criteria
Usually follows the template: As a role, I action so that value.
The story is a promise of the conversation.
INVEST
- Independent: stories should be implementable in any order
- Negotiable: invitation to a conversation; the product owner and development team should be able to discuss the story and make changes to it if necessary
- Valuable: should serve a purpose to the customer. A beautiful backend and no frontend will be useless to the customer
- Estimable: development time can be estimated
- Depends on team experience
- Spike may be required to make an estimate
- Larger stories are harder to estimate. Hence:
- Small: KISS. Larger stories are harder to estimate too
- Testable: the story and acceptance criteria are understood enough that tests can be written for it
Ask if you can break the story down further and still get value from them. If so, break it down.
Promote the story into an epic if:
- The story is vague or contains undefined terms
- e.g. ‘user can see item details in the list’. What details?
- Uses conjunctions or has multiple use cases
- Has hidden/unexplored business rules
- e.g. how long is cart content stored? What type of users can access this functionality?
- Has multiple display possibilities
- What devices does it have to work on? Mobile? Desktop? IE?
- Does the data have to be available in multiple formats?
- Has exception flows
- e.g. what happens after n failed login attempts
- Has unspecified data types or operations
Validating Requirements
- Valid: does the requirement reflect the users’ needs
- Consistent: do any requirements conflict with each other
- Complete: is the definition self contained
- Realistic: does your current technology/knowledge allow such a feature
Common practices:
- Review: talk with stakeholders and systematically go through requirements
- Prototype: build proof of concept, or write some sketches
- Test cases: from the user’s point of view, make sample usages
Slicing Tasks
Don’t have people dedicated to a particular layer of the project (e.g. frontend, backend, database):
- If one person fails to deliver, all the work will be wasted
- Causes tunnel vision
Instead, tasks should involve the whole stack:
- This allows you to deliver partial stories
- Greater focus on user needs and added value
SMART
SMART tasks are:
- Specific: everyone on the team has a full understanding of the task
- Measurable: the team has agreed on what ‘done’ means and the task has acceptance criteria
- Achievable: the task owner should be able to finish the task and/or ask others for help
- Relevant: the task provides value to the customer
- Time-boxed: the team has a rough estimate of how long it should take