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.

Problem in Scrum: Inability to prioritize the architectural and design tasks – Part 1

Over a period of time, some of the discussions that I have had with fellow managers, and more specifically with managers who play the role of Scrum Masters come to a conclusion revealing a weakness in Scrum implementation. Projects where there is initial time spent on planning the architecture and design for the end project tend to have a good design that is scalable, where the individual components (and the flow between them) and the overall design has been well thought out. Sometimes, the amount of time spent in design and architecture seems like an overkill, but in most cases, the amount of time spent is the amount of time required for such activities.
However, one of the biggest problems that has been seen in the implementations of Scrum that I have observed relates to the planning for design tasks. In a typical waterfall methodology, the schedule is split into properly defined and demarcated times for the implementation of all the design work, and the product seems all the better for that. However, when you get into the game of having a Sprint where all the User Stories for that Sprint should be implemented by the end of the Sprint, where the Product Manager defines all the User Stories (and is lead to believe that the Product Owner controls a large chunk of what the engineering team is actually doing). As a result, when you have design tasks that could take multiple Sprints to complete, many times the engineering team cribs about the limited amount of time that they get for doing such a task and believe that the design work is not really complete and can cause problems as the project schedule moves ahead.
Consider the case where the User Stories are defined and added to the Product Backlog. Ideally, these should include the tasks related to design and architecture so that they can be properly prioritized and planned for completion in the required Sprint cycles. But, when the overall requirements are not constant, or are broken down into small parts, it does get more difficult to come up with a proper and structured design document which covers the need. In addition, for many teams, it can be hard to convince the Product Owner about the need to do large architectural tasks, especially when they do not relate to features, or may be needed for features that may or may not be required.
Overcoming such challenges requires a lot of planning, and some work outside the regular Sprint planning cycle, but teams need to do this in order to ensure that they have a good design.

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>