Hi everyone and thank you for visiting my blog!
For today’s post, I’m going to share with you one of the recent Product Backlog Refinement Session I conducted together with my System Analyst, Ace. While our Developers were actively working on with their sprint backlog items, me and Ace decided to refine our product backlog today as set a target of generating at least two to three user stories that we can prepare and categorize them as “sprint ready” prior to the sprint planning.
What is a Product Backlog if you may ask?
According to the recent Scrum Guide as of 2020, is an ordered list of everything that is known to be needed in the product. It is the single source of work undertaken by the Scrum Team. It is managed by the Product Owner, who ensures it is transparent, well-ordered, and continuously refined to reflect changes in requirements and priorities. The Product Backlog items often include features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
Revisiting our Product Backlog
Initially, I already made a list of our own version of the product backlog with which is based from our assessment of our Product Vision. Whilst achieving our Product Vision is a long term goal, we dissected that into a small and achievable milestones we called Product Goals. These product goals were then further decomposed into a high-level to do list needed to be accomplished to release the product, the Product Backlog.
On the section of this video, I shared with Ace, our syste analyst, the lists of the Product Backlog I defined for our first Product Goal of Dealogikal Version 2. Below are the lists of the said items:
- Register and Authentication
- Order / Deal Management
- User profile management
- Notification System
- Device Responsive
Refining the Product Backlog and Selecting a User Story
After we had a quick warmp-up backlog refinement session, Me and Ace then proceed to refine the product backlog. By doing so, I reprioritize the existing lists and adjust them based on were we are at in the development. The reprioritized items are the proceeding flow to our current sprint.
Finalizing and Defining a Sprint Ready User Story
Me and Ace then get to a point on selecting the next user story we are going to be refining with. This user story follows through one of the user story our dev team is currently working on this sprint. They are developing the flow of the system where the admin is going to receive the uploaded deposit slip of our buyer. The next process the admin needs to accomplish with is to verify the payment and disburse the payment to its respective vendors. These said vendors, namely the supplier and logistic, are the ones that are going to provide the items and the logistics services.
The user story we identified by ace is as follows, [Order Management] ADMIN – As an Admin, I want to disburse payment to the vendors.
Below are what we determined as its acceptance Criteria:
Acceptance Criteria
Given:
- Buyer user already closed the order
- Buyer already booked the order
- Buyer already submitted or upload a deposit slip
- Admin already verified the deposit slip
When:
Admin clicks on Payment Menu, clicks Disbursement Tab
Then:
- System displays the lists of verified closed orders
- System displays the supplier and the logistic of the selected verified closed order
- System should enable the admin to see the details of the breakdown of the amount to each corresponding vendors
- System should enable the admin to upload deposit or payment to each corresponding vendors
- System should enable the admin to see order details
- System enables the admin to send uploaded deposit slip to each corresponding vendors
Our system analyst also determined its potential specifications below and our Definition of Done.
Features / technical specification:
- Modal
- Tab navigation of the vendors
- Upload functionality
- Succesfull upload identifier
- preview button
- Submit button
Definition of Done
Admin can have visibility of the verified closed orders, can upload deposit slip for payment disbursement to each vendors involve in the closed order.
Closing our Product Backlog Refinement Session
After a thorough discussion on defining the acceptance criteria, me and Ace were finally able to considered the selected user story, a “Sprint Ready”. Meaning, it is now a decomposed fraction of the Product Backlog and having a detailed acceptance criteria with which, we are going to be used as a reference for our developers during our sprint planning. This user story is now being listed as one of the top backlog items that we are going to cover on our next sprint.
Thank you for reading this blog post! I’ll be posting the latest update for our Sprint 16 soon.
Cheers!