marvinenriqueznavarr.com

Hi and thank you for visiting this blog post.

Our team is gearing towards a new sprint on this software project. We had just finished the sprint cycle including the recent one we did on presenting the new increments and gathering feedback from our stakeholders which is the sprint review and checking on the team’s insight and continuous improvement through our retrospective. At the end of a sprint cycle is a the beginning a new one which is going to be initiated through sprint planning, a scrum event we’re the scrum team is going to identify what needs to be done in the sprint.

Team’s Capacity

Before we brainstormed on what would be the sprint goal for this sprint, I started off on checking the team’s capacity. In agile, it’s the process of checking each team members availability to work in the sprint. For a two week sprint, each developer will have 80 hours coding. That’s 8 hours per day 5 day(working days), 10 days in two weeks. I use the Capacity hours as the developer’s way of selecting and providing the estimated effort of a technical tasks we identified during decomposing a user story.

In this sprint, I only assigned 56 hours per dev which is about 70% of their capacity hours. The remaining 30% will served as a buffer for them should complexity arise on the tasks they are working.

I also asked my developer team members if one of them are anticipating to file a leave during the sprint. If so, I will subtract the number of days, converted into 8 hours per day, they will be on leave to the total number of hours they will be working on the sprint which is 56 hours. This allows the scrum team to adjust their development approach on that sprint. In addition to this, I also check on any holidays within the two-week sprint period and will subtract that number of days the holiday will last to the whole team’s capacity. 

Doing this process on identifying team’s capacity enables them to identify the team’s total development and helps the team on identifying how many user stories they can develop within the two-week sprint period. 

Fortunately for this sprint, all dev team members are available. The total capacity for the 4 dev team for this sprint is 224 hours.

Identifying the Sprint Goal

After my team were able to determine our capacity dedicated for this sprint, I then navigate them to one of the critical section of the session, Identifying the sprint goal for this sprint. To help them identify, we coursed through the swim lane I created during requirements gathering and assess where we are currently at in terms of the delivered features versus the remaining ones to be developed. By checking on the swim lane diagram, we identified that the previous sprint we delivered tackled the Buyer’s payment process and half of the admin’s facilitating the Buyer’s payment. With that, I proposed to the team to focus our effort this sprint on proceeding to develop the next process of the process flow, to enable the buyer to disburse the payment to the vendors and service providers. We also discussed still, the three valuable questions of identifying the sprint goal during this session.

After going through the process, my team finally determined the sprint goal for this sprint which is:

Enabling the admin to disburse payment to logistic and supplier, Enabling the logistic and supplier to receive disbursed payment, Enabling the Supplier to upload their SO(proof of sale), Enabling the admin to confirm supplier’s uploaded SO.

Sprint Ready User Stories

Prior to this sprint, me and my system analyst, Ace, conducted our backlog refinement session and listed possible user stories that our developers will be working on the next sprint. These user stories were identified based on the whole product backlog and the process flow Ace outlined with. We listed them in the Proj4.me, ensuring that these are sprint ready items meaning, each items have acceptance criteria and can be a 2 to 3 days worth of work, and organized them based on priorities. We also put tag to the identified user stories with “sprint ready” in our Proj4.me so it would be easy for us to spot on them during sprint planning because tag feature in Proj4.me has color indication that sticks to your card item. One user story we listed is:

[Order Management] ADMIN – As an Admin, I want to disburse payment to the vendors

This user story enables our admin to disburse payment to the Suppliers and vendors who were selected by the buyer during the quotation process in the platform. These are its detailed 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
Features / technical specification:
  • Modal
  • Tab navigation of the vendors
  • Upload functionality
  • Succesfull upload identifier
  • preview button
  • Submit button
  • API Integration of active quotation breakdown details
 
After letting my developer team members review the acceptance criteria, we then continued to let them carefully list all the technical tasks required to complete the development of the this user stories. These tasks span from process flow to designing the UI down to the front-end and API integration. These technical tasks are:
  •  Design Modal that contains the vendor and supplier details UI 
  •  Implement snackbar & bell notification in buyer terminal if payment already verified. 
  •  Develop an API responsible for fetching the breakdown of the amount for the supplier & logistic. 
  •  Develop a modal that contains the logistic and Supplier details  
  •  Design Disburse List Page UI 
  •  Develop an API to submit the payment verification and notify the buyer that payment already verified 
  •  Develop an API to upload disbursement details including deposit slip url. 
  •  Develop  a lists of verified closed orders  
  •  Process Flow of this User Story 
  •  Develop an API to fetch the payment/quotation details for the visibility of the buyer. 
  •  Integrate API for confirming payment verification 
  •  Develop an API to fetch the list of verified payments for disbursement. 
  •  Integrate an api to fetch the payment/quotation details to replace dummy data. 

After a thorough breakdown of the required technical tasks to develop the user story, we then held the part of the session on letting the team members select their task and provide their estimated effort to complete the selected task. On this sprint, I selected the task to develop the UI for this user story and shared my estimated efforts to complete the UI designs. Ace, our system analyst, selected the task to provide us with the technical specifications and critical information that is fundamental for this user story including the process flow, the data for the table to be used in preparation for the API and more. CJ and Alex, our fulls tack dev, selected those back-end tasks while our front-end Janm, selected to develop the front end.

The Rest of the User Stories that is aligned with the Sprint goal

Through out the session, my dev team were able to decompose, assigned, and estimated the 4 user stories we were able to determine during this sprint planning. Here are the remaining 4 user stories:

  • As a supplier, I want to receive the payment deposit, so that I can proceed to facilitate order
  • As a logistic, I want to receive the payment deposit
  • As a Supplier, I want to upload my SO(Proof of sale)
  • As an admin, I want to receive confirm SO send by Supplier

All of these user stories are now documented in our Proj4.me and are carefully organized based on the task owners, dependencies and their task deadlines.

To conclude

Thank you for taking the time to read through this detailed account of our recent sprint activities and planning processes. As we move forward, our team remains committed to continuous improvement and delivering high-quality increments. With the sprint goal clearly defined and our capacity well assessed, we are poised to make significant progress in enabling the admin to disburse payments and enhancing the overall functionality of our platform.

By maintaining a focus on effective sprint planning, transparent communication, and thorough backlog refinement, we aim to achieve our objectives and meet the needs of our stakeholders. Stay tuned for more updates on our progress and insights into our Agile practices.

Your feedback and insights are always welcome, so feel free to leave your comments or reach out to me directly. Until next time, keep striving for excellence in your Agile journey!

 

Best regards,

Marvin E. Navarro

Leave a Reply

Your email address will not be published. Required fields are marked *