A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum: Breaking down features into sub-tasks that can help provide a better picture

Once upon a time, there was a world in which there were these huge features. They would be 7 days long or more, marked as such on a MS Project schedule, and on a regular basis (probably not on a daily level), there would be an update on the percentage completion of the feature. This could even be on a weekly level, which would mean that people dependent on the completion of a feature (which could be other developers who had a dependency, or testers who would need to spend time on this feature but for that, would need to have accurate details of when the feature will actually be available to them). The problem with all this is that it is not enough to only know whether a feature is going to be complete in a certain time period, but even more clearly, what is the current amount of completion of the feature.
There needs to be a tectonic shift in operations once you get to the Scrum world. You cannot have features of such length. The typical amount length of a task in the Scrum work would be around 1-3 days, but there are plenty of tasks that are less than even 1 day. Breaking up a feature into such tasks is not easy, takes a lot of thinking and worrying, but as the team gets more experienced at this, they will get better at this. However, whether they are able to do it well or not, doing it is not a negotiable activity – every team working using a Scrum methodology will need to work out how to change their mindset so that they are able to define their tasks to be of this short length.
There can be some amount of confusion about whether these tasks are such that they need to be able to be tested, but there is no condition that a task always needs to be such that it can be tested. There can be plenty of such tasks that are design or architectural related, and for which there is no condition that they need to be handed over to the testing team. In fact, there can be multiple such tasks being done by a person that will not be available to the testing team, and in fact, form the foundation for other tasks that can later be handed over to the testing team. Doing this is difficult, but it helps to also understand the progress of the feature, since you know exactly which all tasks together make up the feature, and know the amount of tasks that are completed, which help figure out the percentage of the feature that has been completed.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>