Do you know the 3 steps to a PBI?
15/02/2016 8:23 AM by
The lifecycle of a PBI can be broken down into 3 steps:
- Take the next PBI that was created by the Product Owner
- Is the PBI ready?
Check your PBI against your Definition of Ready. “Ready” PBIs must have Acceptance Criteria. A good Definition of Ready also encourages a test first mentality in requirements e.g. Use Spec Flow (Given, When, Then) and/or create Test Cases and Test Steps first.
- Break down your PBI into tasks.
- Don't forget to make a task for testing! (So that it is visible in the task board). Note: You can also customize the kanban board by adding a new column for testing, but we recommend adding a testing task to the PBI instead.
- Figure: Adding a new "Test" state. This is only visible in the product backlog and not the sprint backlog
- Figure: Testing Task added to PBI. This is the board the team will use for 90% of the sprint, so testing should be clearly visible here.
- Create a branch for your PBI
- On the Web Task Board, move your Task into “In Progress”
- Code, code, commit… Code, code, commit (Red Green Refactor)
- As you complete tasks, move them to “Done”
- Repeat 2-4
- If you want feedback early, record a video. E.g. Snagit
Is the PBI “Done”? Check your Definition of Done, and then the Tester:
- Open a pull request
- Do an "over the shoulder" check of the code
- Use Microsoft's "Exploratory Tester" Chrome extension to test the app
- Make changes based on feedback (and then get more feedback)
- Merge changes to master, this automatically deploys (to either Test, Staging or Prod based on process maturity)
- Send a "done" email
Congrats. Your PBI is now ready to be demonstrated during your Sprint Review! (Note: This is also the same process you follow for a Bug work item)
- Good Figure: This image includes all the important steps in a PBI lifecycle. Print this "SSW 3 Steps to a PBI pdf" and put it on your 'War Room' wall.
Do you feel this rule needs an update?