Suppose you are on a team that is working on a product. Let’s say that your team has a backlog of user stories. It is the responsibility of the product owner to determine which user stories to work on in which order. However, the product owner will need some help from the development team in order to feel more certain about how to do the prioritization. How does the product owner do this prioritization? There are a couple of factors that the product owner will take into account.
The product owner has the domain knowledge and understands the business value that each user story gives. One thing the product owner might do is to take each user story and assign points to each story based on business value. Perhaps one user story is considered a 5 business value points and another user story is 10 business value points. This would mean that the user story that is 10 business value points is twice as valuable as the 5. The product owner could then look at each user story and prioritize based on which user stories have the highest business value points.
There are some problems with this. One problem is that some of these user stories might not actually add any value alone. User stories should be broken down very small such that the team can complete multiple of them in a sprint. Each user story adds a small amount of functionality. But it can be the case that this small amount of functionality alone is not useful to the customer unless another small amount of functionality is also added. Suppose user story A cannot add business value unless user story B is also done and vice versa. Neither of these user stories individually add business value so it doesn’t make sense to put business value points on these. We also want to make sure that when we are prioritizing, we do user stories A and B consecutively. We don’t want to complete user story A, complete user story C, release user story C, complete user story B, then release user story A and B. We want to be working on stories for our next release at any point in time. What we can do here is place the business value points at the epic level. Perhaps there is an epic that contains user stories A and B. When putting the business value points at the epic level, we now have something that independently adds value. We can then choose when to work on the epic. Once we get around to working on the epic, we can do user stories A and B consecutively. If a tiny user story is independently releasable, then it is OK to place business value points on it instead of at the epic level.
Now, the product owner is able to look at the business value points of the work that needs to be done. The product owner could go off of these business value points to determine which work to work on in which order. However, going off of business value points alone is not enough information for the product owner to be able to prioritize work.
Suppose a user story A has twice as much business value as user story B. We should do user story A first, right? Not necessarily. What if user story A is predicted to take four times longer than user story B? We may want to do user story B first in that case. So the product owner needs to have some knowledge about how long a user story might take in order to prioritize it. Which people are most likely going to have the best guess about how long the work will take? The people doing the work. This will be the developers.
So the developers can take a look at the user stories and assign story points to the work based on how long they think the work will take. If story A is predicted to take twice as long as story B, then that means that story A is going to be twice as many story points as story B.
Now that the stories are story pointed, the product owner is a lot better equipped to prioritize the stories. One thing the product owner might try to do is come up with some formula for prioritizing user stories such as business value points divided by story points. This would be an OK approach. However, suppose you have the follow situation where there are three user stories that are independently releasable:
In this scenario, the business value points divided by the story points comes out to the same number. However, it looks like we would want to do user stories B and C before user story A since user stories B and C lead to quicker releases. Suppose user stories B and C might take one month each and user story A might take two months. Let’s compare the following two scenarios:
In both of these scenarios, we have the same amount of work done in a 4 month time period (everything released). However, in scenario 2, we already have something released after 1 month whereas in scenario 1, nothing gets released until the second month. So going off business value points divided by story points is sub-optimal. So there is still some benefit to favoring shorter user stories, even if the business value points divided by the story points are equal. Regardless of whether or not you come up with a formula, having the business value points and story point estimates help out a lot in prioritization.
Let’s return to the previous example:
We previously stated that it felt like a good idea to do user story A last. However, we cannot infer that doing user story A last is the best approach just by going off business value and estimates alone. Suppose user stories B and C are considered incredibly likely to fail but user story A has minimal risk associated to it. We might want to go with user story A.
So stories have some amount of risk associated to them. The risk would be the chance that the project does not meet it’s objectives. Maybe the project begins getting coded up and the developers learn something unfortunate. Maybe they determine the project is no longer possible. Perhaps the objective was to take A, B, an C as input and return back D, E and F but it was later determined that A, B, and C is not enough information to get D, E, and F. Or the more common scenario when things go wrong is that the project is still possible to do but it will take significantly longer than predicted due to an assumption that turned out to be incorrect. Maybe there was a 3rd party library that was going to do the bulk of the work for our project. Perhaps we learn in the middle of the project that this 3rd party library doesn’t quite do what we need. We either make the change in the library or we completely re-invent the wheel and produce everything from scratch. We talk to the people overseeing the 3rd party library and they reject our change. We estimate that writing everything from scratch will add 5 years to the project. Perhaps we have to end up throwing away the project we were in the middle of working on.
So having information about risk is helpful to determine what to do in which order.
For the most part, we have talked about prioritizing between independently releasable work so far. If you have some stories that are not independently releasable, you place business value points at the epic level and prioritize the epic against other independently releasable stories which may or may not be epics. This prioritization is done by the product owner based on knowledge of business value, estimates, and risk. We want to prioritize working on high business value, low time estimates, and low risk first. Suppose we do this exercise and it turns out we will be working on an epic next. Let’s say this epic is made up of user stories that are not individually releasable. Maybe all of the user stories on this epic have to be complete for releasing to make sense. At this point, there is no business value associated to each story within the epic since these stories aren’t individually releasable. How do we determine which of these user stories to do first?
There are a couple factors needed to make this decision. The first thing to think about is the risk. If there is a large chance that the epic will fail somehow, it would be better to fail after being 10% of the way through the epic rather than failing when you are 90% of the way through the epic. This way less time was wasted when the project gets thrown out. So if an epic contains high risk work that is mandatory for the release, it would make sense to do that first. If there is any high-risk work that is not mandatory for the release, that would either be a really low priority or dropped. Another thing to think about is how much feedback a story is predicted to get in a demo. Getting feedback earlier will mean there is less re-work needed when the stakeholders determine they don’t like the direction the project is going in. Lastly, we should try to keep dependencies between stories to a minimum but there can always be a chance that one story depends on another which overrides any other factors that go into prioritizing the stories. So now we know how to prioritize non-releasable stories within an epic. How do we prioritize tasks within a user story?
Tasks are broken down along technical lines so that type of prioritization is done by the developers. Dependencies between tasks will be the largest contributor in terms of which task to do first. Other than that, risk would be the next biggest factor in determining priority of tasks. Likelihood of getting feedback in a demo would play no role in determining which task to work on next within the user story since only completed user stories are demoed.
Business value, time estimates, and risk are the three biggest factors that need to be considered when trying to prioritize work. We want to always be working on code for the next release at any point in time. As a result, it makes sense to try to assign business value points at the epic level if the stories within the epic are not independently releasable. We would then start by prioritizing between releasable work. We would try to prioritize doing work that has higher business value, lower time estimates, and lower risk. After we have a guess as to what will be included in our next release, we would then want to do the high-risk mandatory stories first so that if the project fails, we end up having less time wasted. After that we would try prioritizing based on the amount of feedback we might get in a demo. This is a strategy that minimizes time spent writing code that gets tossed or writing code that gets completely re-worked. When it comes to breaking down stories into tasks and prioritizing tasks, that can all be done by the developers. The order of those tasks will primarily be determined by dependencies between tasks. Other than that, the remaining prioritization for the tasks within the story will be based on risk. To see how defects affect prioritization, you can read a separate blog post here.