Like many other start-ups, our team uses Jira to track sprint and work progress. Jira is undoubtedly an excellent tool in sprint management, but it lacks a standardised approach in logging issues and managing sprint. it is entirely up to you on how you want to use its features. For this reason, there has been a lot of debate between developers and Product Owners on how to organise our sprints.
The first problem that we came across is how to define a user story. The most used pattern in defining a user story is:
As <Actor>, I want to <Objective> so that <Value>.
For example, the user story for a Google sign-up feature can be:
As a user, I want to sign in with Google so that I don’t have to remember my username and password.
The actor here is “user”, the objective is “sign in with Google”, and the value is “I don’t have to remember my username and password”.
The example user story definitely has business value, but to deliver this story, each team member will have to carry out different tasks like:
- A back-end developer needs to do database work and connect to Google sign-in API service.
- A designer needs to come out with the UI for the login page.
- A front-end developer needs to create the UI flow according to the designer’s specification.
The question now is since each member contributes differently towards the delivery of the story, should we break the example story further into smaller chunks to represent the work for back-end, front-end and design? If yes, then there are other problems like:
- How do we keep the original business value of not needing the user to remember the username and password?
- Do we expect the Product Owner to know all about the development and design process? The front-end developer might not know the designer’s effort, or the back-end developer might not know the front-end pains, let alone the Product Owner!
Another problem that bogged us was, should we use story points or time consumed to track progress? If we use story points as an estimate of work, then it does not represent business value. On the flip side, if we use story points as an estimate of business value then it does not represent efforts. To us, we think both business value and efforts are equally important.
Finally, what about all the ad hoc works that aren’t directly contributing to the stories like onboarding a new team member? Shouldn’t the team acknowledge the effort in a sprint too?
After rounds of debate and discussion between Product Owners and members, our team came out with our own agile framework surrounding the following three pillars:
- The business value must be measurable to justify work.
- Total time spent is the best representation of work.
- All work must be recognisable.
The business value must be measurable to justify work
When writing a user story, the Product Owner must give a numerical representation of how much he/ she values the story as story points. The higher the points, the greater the value. If the team have more than one Product Owners, they need to reach a consensus on how much each story values to them. Also, we do not allow the same story points to appear more than once in a sprint. This is to “force” Product Owner to give priority to each story. You can adopt any scale when giving value to a user story. Our team has adopted a scale between 10 to 100. For us, if one story scored 78, and the other scored 40, we know that the Product Owner value the prior two times more than the latter. Also, by prohibiting Product Owner to repeat story points in a sprint, the team can focus on what’s important. The rule of thumb is if a sprint can only fit one user story, the one with the highest story points will take precedence.
Total time spent is the best representation of work
As discussed, we want to record both business value and work estimates. Since we use story points to record business value, the team member has to record work estimates elsewhere. We use Jira’s subtask to record individual work in the story. In each subtask, the owner can assign his/ her work estimates (in hours). Finally, adding up the work estimates of all subtask is the effort representation for the story.
Now that we have both business value (as story points) and work estimate in a story, we can then execute them based on something we called The Focus Quadrant:
- Focus – The Focus quadrant groups all stories that have high story points and low work estimate. Team members should clear all stories that sit in this quadrant in the quickest possible manner to maximise story points burn down.
- Priority – Stories in this quadrant should have higher priority as they deliver high business value to the software. Team members should immediately start working on the stories in this quadrant after clearing everything in the first quadrant. Ideally, team members should also clear all the stories in this quadrant before the end of a sprint.
- Backlog – Stories in the Backlog Quadrant will remain in the backlog until the team clears all stories in the first two quadrants and there is still time left in a sprint. Even though the business values are low, these stories require little effort to complete. Completing these stories will increase the sprint’s productivity.
- Discard – Stories in the Discard Quadrant does not mean that you should throw them out. It is common for the business value and work estimates to change as the software grows and matures. For this reason, we should keep these stories in the backlog and review their business value and work estimates from time-to-time.
All work must be recognisable
Finally, we use Jira’s Task to record works that don’t directly contribute to a story. Task in Jira does not carry story points, but the owner can record their work estimates and add them to the running sprint. Doing so will distort the original estimate of a sprint, but we think it is more important for the sprint to capture the unexpected change in workload rather than tries to “stick to the plan”.
We have been running on this model using Jira for a few sprints now and this it seems to work well. I think the Focus Quadrant helps:
- Product Owners to draft user stories that maximise the software value to visualise if the value of a story justifies the effort in delivering it.
- Team members to focus on productivity that maximises business value and acknowledge the contribution of every individual.