Hi everyone, and thank you for visiting my blog!
Today, I want to share an update on the current sprint my Dev Team is working on. Recently, we reached a shared understanding and agreement to implement a new sprint process discussed during our ad-hoc meeting. This sprint also marks our first use of Proj4.me as our project management software for task allocation and transparency, helping us track the progress of the project or sprint more effectively.
Identifying the Sprint Goal
At the start of every sprint planning, I ask my Dev Team three key questions to identify our sprint goal:
- Why is this sprint important?
- What can be done in this sprint?
- How will the chosen work get done?
Answering these questions helps my team focus on which part of the product backlog they will work on, ensuring a clear and shared vision of what can be achieved within the two-week sprint period.
Once we identify the relevant part of the product backlog, we proceed to select a user story and decompose it into technical tasks. This approach helps us maintain clarity and efficiency throughout the sprint.
Reviewing our Product Backlog
Before we head into selecting a user story, the team revisited our product backlog and conducted a quick brainstorming to figure out which portion of the whole product goal we are going to select our next target for the sprint. In this current project we are working on, we have 6 stages of our user to complete one order transaction. As of to date on our development, we successfully developed 2 stages already and we come into a team agreement to work on the next payment stage.
Identifying user story
The team’s product owner then shared one of the user stories allocated for this sprint. Typically, a user story should have been already qualified to our selection process called INVEST. A popular acronym to identify a user story which stands for Independent, Negotiable, Valuable, Estimable and testable. It should also be doable for at least 1 to 3 days worth of work. The selected user story is stated at “as a buyer, I want to submit payment so that I can book and receive my order.” The team then agreed to have this first user story to be decomposed and started sharing ideas on how they can translate that requirement into a functional increment.
Decomposing the user story and its Acceptance Criteria
Before the team started to breakdown the selected user story, we come into an initial discussion on what would be its acceptance criteria. We outlined a few:
- buyer can have a preview of the order details before proceeding to payment
- buyer can submit payment while reviewing the order
- another verification before submitting payment
- buyer can see details of the order(page)
- buyer can upload payment(deposit slip)
- buyer can review the uploaded deposit slip
- buyer can upload deposit slip while using mobile phone
- buyer can upload payment by accessing file manager
The team then started sharing technical tasks that could lead to develop the user story guided by the outlined acceptance criteria. One of them shared to create API Gateway to handle saving of payment details request. One front-end dev shared import functionality that enables the platform to import image. The UI designer also started determining the function of the interface to enable the user complete the task.
Task allocation and Estimation
After the team concluded the needed tasks to develop the user story, we then proceeded to have each one of them select their tasks and let them provide the estimated effort to complete each of their selected task. They started sharing about how many hours they can complete the selected tasks. The team were proactively sharing some constraints, complexities and tips. After a through discussion, defined the story’s definition of done and a shared agreement of accountability and transparency, we collated all developer’s estimated effort on the selected user story to determine if we can develop it within 1 to 3 days with which we somehow identified to fall into the category. So, we then proceeded to tackle the next user story.
Proj4.me
While we were conducting the sprint planning, we simultaneously lists all necessary tasks to complete this sprint and have it listed and stored to Proj4.me, a project management software with which the team agreed to use throughout the development. Using a PMS enables me, as a Project Manager, and the rest of the team, have visibility of all the sprint backlog items thus foster task transparency and schedule adherence ensuring that the sprint is going to be well managed and successfully delivered within the allocated timeline.
Closing out the Sprint Planning
Finally, the team were able to come up with the plan to follow to successfully accomplished the sprint and deliver an increment of the software for the next two weeks of the development called, the Sprint backlog items.
What’s next?
The team then dive straight to working each of their selected tasks. We closed out the first day of the 2 week sprint with a detailed plan, our sprint backlog items, and determined to successfully accomplish the sprint by turning an user requirement, the user story, into a functional, releasable piece of the application, an increment.
I’ll be posting few of our Daily stand-up meeting on this sprint.
Thank you for reading and see you into my next blog post.
Cheers!