While working in an agile environment, you may be assigned a user story that requires a very large amount of time and effort to implement. Typically, any user story estimated above a certain number of points should be broken down into multiple smaller, actionable user stories. Unfortunately, this does not always happen.
Perhaps the full scope of a feature was unknown when the story was originally estimated, turning a previously estimated four-point story into a 16-point story. Maybe the user story focused on updating an existing feature, and the current architecture of the system will not support the new requirements, so more effort is needed to make the desired changes.
But it’s not always easy to break up a large story into smaller stories, especially when you can’t implement one part of it without leaving the whole application in a non-functioning state. I have encountered this a handful of times, and I’ve made the situation easier to manage by splitting these stories into tasks.
Here’s my approach.
1. Break Up Large Stories Into Tasks
Even though a story might be difficult to split into smaller pieces, it’s often possible to generate a list of tasks that are necessary to complete the story. Skipping this step makes a number of things more difficult, such as determining when to check in your changes and communicating your progress with your team.
Predetermined check-in points
If you don’t know what you’re trying to accomplish, determining a good point to check in your changes is quite difficult. Starting on a large feature without a plan of attack typically results in commit messages of the form: “WIP feature X,” or “Wrapping up feature X.” There are ways to amend these commit messages, but adding specific points to check in your changes makes reviewing pull requests easier for the other members of your team.
For example, let’s say the story you’re working on requires a significant redesign of the UI on a particular page. One of the tasks for this story could involve applying the new color scheme that was defined in the story. You can summarize this change in a meaningful commit message such as, “Use new color scheme on Page X,” and the
diff of your changes would reflect that. The intent is clear, which makes these changes simple to review.
As you work on the rest of the tasks for the story, you’ll end up with a clearly defined set of changes with meaningful messages for others to review.
Improving team communication
Communicating your progress on a large story can also be tricky. I have often been the optimistic team member at standup that says, “I’ll hopefully be done with that by the end of the day!” The problem is that, more often than not, I usually end up saying that three or four days in a row.
Determining how far you’ve progressed through a large story, especially when you need to communicate that status to other members of your team, is often difficult. Creating smaller tasks to complete along the way can help. It’s much easier to say, “I’ve completed 3/5 tasks for that story and I should be able to wrap up the last two after lunch,” than, “I’ll still be working on that story. It’s nearly done, and I’m hoping to finish it today.” The former provides metrics and a timeline for completion, whereas the latter provides no real information other than an approximate guess about when it will be finished.
2. Run Tests Frequently
Automated tests are a great way to verify that your code performs the way you expect. After a long period of time, a project probably has an established test suite to ensure that any future changes will not introduce regressions elsewhere in the system.
As you’re working on each task, it’s important to make sure your test suite still passes after your changes have been applied. Leaving test fixes for the end of an implementation is a good way to add extra work for yourself. Frequently running your tests saves time in the long run since it allows you to catch any bugs that may have been introduced while completing a task.
3. Create Separate Tasks for Refactors
As you’re working on individual tasks, you will likely come across some code in desperate need of a refactor. It’s important to take note of these areas, but don’t let them take your focus away from the task at hand. Instead, if it’s something that you feel is necessary to take care of as part of the current story, add another task to the story.
If the refactor is not related to your current story, it might be better to leave a
TODO comment nearby. Then again, those don’t always work.
These are some of the strategies that I typically use when trying to manage larger stories, but I would love to hear your suggestions to make this easier!