Category Archives: Uncategorized

Scrum artifacts: the product backlog

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.
A product backlog in a software tool
Physical board

Scrum introduction, what is Scrum?

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.

1000px-Scrum_process.svg

Scrum Ingredients

  • Artifacts: things (kanban board, product backlog)
  • Roles: what people do
  • Events: types of meetings

Priority

  1. Transparency:
    1. Of work in progress;
    2. On product backlog (work to do)
    3. Meetings: Only 5 easy meetings
    4. Simplicity: 3 types of roles in the team
  2. Fixed timelines: iterations, sprints.
  3. Strong product vision (evolution);
  4. Flexible scope in the iterations

Are you ready to see the overview of Scrum?

Team characteristics

  • 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

  • Product Backlog
  • Sprint Backlog
  • Burn-down chart
  • User Stories

And (possibly):

  • Release burn-up

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.
A product backlog in a software tool
Physical board

Scrum artifacts: User Stories

Scrum: Artifacts: User Stories

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

CCC (mnemonic)

  • 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.

INVEST (mnemonic)

  • 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.

Three ways to handle bugs while on a DEATH MARCH loaded with technical debt?

A short consideration about the bugs in Agile (for Scrum teams): A team works together on a user story. And the definition of that being done includes that all development work is done and that all the issues or problems have been fixed before ending the sprint. However sometimes a user story can be interpreted in different ways. Or sometimes teams procrastinate in fixing bugs and bring in new work. They falsely consider the earlier work done. But there’s a big beast under water…

Situation: the product as shown is not good for the Product Owner

Possible causes:
1. The user story was not clear enough for the developer: The developer thinks he understands the story but the BA has a different idea about the same.
Solution: create a new story, add it to the backlog and prioritize it so that it comes in the next sprint (or in the same sprint in exceptional cases). The story should have its own title, description, acceptance criteria and should also be demoed – like all the stories.

2. The story is clear but a mistake is made and not seen by the developer or one of the peer developers (peer review is important).
Solution: Two options, create a bug and add it to top of the product backlog, raise it during the call, find a developer who is available to volunteer and implement the fix. Take it offline in a separate call. Or create a new user story instead. Which comes across nicer. It’s a fine line sometimes between: “YOU MESSED UP, I NEED A FIX NOW!” and “no worries mate, you can fix that later… whenever yeah”

3. The developer made the right code but broke another set of code
Solution: Make sure that continuously, in every sprint, a part of the bandwidth of work is allocated to regression testing. Developers checking whether the existing software, that was made earlier still functions. Make sure that you have this in place if you do not want to end up in a jungle of something called technical debt.

Another consideration
Some teams bulk up so many bugs, while they continue to produce new software. In all cases, me and my peers advise to stop pulling new work but fix the issues at hand first. This might sound simple, but if you have the drive of a deadline coming close it could feel like you should try and create more software first. Which means: you are on a death march.

How to be good at planning poker and story points?

Story Points are easier to understand and work with than most people think.

What are story points?
A Story point is a arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.

So teams size on a piece of work. Is it a lot of work? Is it complicated? Is there uncertainty?

    So three elements:

  1. Complexity
  2. Unknowns / uncertainty
  3. Effort
    Methods:

  1. T-Shirt sizing ( Large, Medium, Small)
  2. Story Points (modified Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100)

Get going
Scrum Master / Team Lead: During a session where the work is discussed, talk about a user story.

    Ingredients

  1. Development team
  2. Product Owner
  3. Scrum Master
  4. Poker cards
  5. User stories / Stickies with stories

Ask the developers to think (NOT to talk) about how complicated it is for a moment. Bring in Scrum Poker cards or get a set of yellow stickies. And write per sticky the Fibonacci sequence (1,2,3,5,8,13). Or small pieces of paper will do too.

Ask the developers to select a card (picking a number) and hold it to themselves. Now when all the people have picked one, ask the developer to open their cards at the same time.

images

What if I am not in the same room (collocated)?
Ideally you are. But if you aren’t, or working remotely for the day; use an online tool, like planningpoker.com made by Agile guru’s and free up-to 10 people.

Voting tricks
There’s some very interesting psychological trick behind the voting with closed cards. The surprise is great, instead of people influencing each other. Some people have bigger ego’s than the others. By not influencing each other the outliers who are more junior – for example – learn a lot from their peers because it always results in a conversation about the work; which evens out problems, reduces unknown elements of that work and so on.

Tricks from an Agile Coach
Some people will always try to quantify a point or a S/M/L size of a User Story into days, hours. People have learned for decades that when they hear the word Effort, that it relates to period of time (hours, man days, weeks). If that’s the case, try to forget the amount of effort you think it takes to finish the work. Instead ask the people to vote for just the complexity.

Getting to a proper Definition of Ready (DoR)

During the refinement sessions we are preparing the place holder stories in the sprint backlog to get to this definition. Only if they are ready, we can bring them in to a new sprint.

User story has:

  • A description (As a X, I want Y, So that I Z).
  • Acceptance criteria (important for definition of done).
  • Story points.
  • How to demo.

So that’s equal for all the types of user stories, may it be a support task with uncertainties in terms of the actual work, or for JIT execution or any other possible work-related task.

Definition of Done (DoD) for a user story (feature)

This definition marks the point where a story is really Done. Now this seems like a cliché but there are many discussions on wether something is really done or not. In order to set the criteria for the DoD we use the acceptance criteria in the user story. This functions like a check-list; if all are checked the story is done.

And when all the user stories are conform the DoD we define the DoD for the sprint.