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 – Paying the tax in terms of setting aside time for technical work ..

I have seen teams go with a very rigid form in terms of their Scrum implementation (and though it might seem odd to mention rigid and Scrum in the same sentence, you can have teams composed of people who like to have their processes clear), and one of the items they really struggle with is about ensuring a balance between the need to do technical work during a Sprint (you know, refining some code / classes, fixing some broke architectural or design issues, and so on) and the need to build features for customers. Now, you could argue that these technical work also eventually benefit customers, but it can be a problem ensuring that the team and the Product Owner are on exactly the same page (and it is good in most cases that they are not exactly on the same page, since what they look at and the factors that drive their decision making can be different). So, when a team member goes to the Product Owner for doing some refinement of a particular code structure (it could be an older structure that is now causing problems), there is no particular User Story or end customer facing feature that this particular work can be slotted into. In some cases, the Product Owner might be convinced, but in many cases, the Product Owner has some specific customer facing features in mind, and having time open for such kind of technical improvements would not fit into these User specific stories.
And this is the perfect recipe for getting into a tricky situation, since there will be work that the technical team deems essential, but the Product Owner has been refusing these improvements. It is also possible that bundled within the technical areas is work that could actually improve the product performance and also some specific features that ensure that the team is able to improve their productivity, and it can get frustrating for the team members to know that this work is also important but does not perceive that the Product Owner is getting the need and is able to do a proper prioritization.
So is there a solution ? Well, a solution suggested by one of my colleagues and which has also been suggested by others relates to setting aside a specific time amount within the Sprint Cycle for such kind of technical work that is not covered under the garb of the User Stories. This may not be easy, but the way to go about doing this is for the technical team to have a good idea of the amount of work required for ‘critical’ improvement, and then have a corresponding discussion with the Product Owner explaining the need for such technical work along with the approximate timeline required. Even in such a situation, it is likely that the Product Owner will not easily agree to everything that is being discussed; but over a period of time, such trust will be developed. Based on such a discussion, the team can set aside some amount of time for such important technical work that cannot be grouped as part of the other regular User stories. However, the team needs to ensure that they are using this time only for essential work, that this time is taken away from other customer facing features, and hence cannot be just used for fixing anything that takes their fancy.

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>