Scrum is a subset of Agile. It is a lightweight process framework for agile development, and the most widely-used one.
A ‘process framework’ is a particular set of practices that must be followed in order for a process to be consistent with the framework. (For example, the Scrum process framework requires the use of development cycles called Sprints, the XP framework requires pair programming, and so forth.)
‘Lightweight’ means that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.
Artifacts: things (kanban board, product backlog)
Roles: what people do
Events: types of meetings
Of work in progress;
On product backlog (work to do)
Meetings: Only 5 easy meetings
Simplicity: 3 types of roles in the team
Fixed timelines: iterations, sprints.
Strong product vision (evolution);
Flexible scope in the iterations
Are you ready to see the overview of Scrum?
Ideal team size: 7 (+/- 2): link to research on team size
Collocation: team in same room
Dedicated team members: work mostly/only with this team
Cross-functional: team members have different backgrounds and should be able to do each other’s work
Scrum Artifacts / Artefacts
Scrum: Artifacts: Product Backlog
List of User Stories.
The requirements for the product are listed in the Product Backlog.
It is an always changing, dynamically prioritized list of requirements ordered by Business Value.
Requirements are broken down into User Stories by the Product Owner.
User stories are part of an Agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
User stories are actually narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system. A true user story is a metaphor for the work being done. It is not a highly documented requirement but rather a reminder to collaborate about the topic of the user story—in other words in agile development (good agile at least), the documentation is secondary to the collaboration. User stories aren’t agile in and of themselves. Instead, their underlying agile values—collaboration and just-in-time definition—make user stories a good agile tool. Formality is specifically removed from the mix and specification of the user story is pushed as late as possible.
More about User Stories
Card: we need an item: digital or a card on a wall.
Conversation: the team needs to talk about the card
Confirmation: the team needs to confirm that we understand the item.
Independent: self-contained, no inherent dependency on another PBI
Negotiable: up until they are part of an iteration (sprint) they can always be changed and rewritten.
Valuable: a User Story must deliver value to the client / user / customer/stakeholder(s)
Estimable: Team must be able to estimate the size of a User Story
Small: small enough to plan / task / prioritize with a certain level of certainty; <50% of effort.
Testable: must provide necessary information to make test development possible.
Working globally on Business Transformations, Agile teams and programmes