How to decompose a sprint in scrum?

Question

I´m struggling how to decompose a sprint in SCRUM. I know in many cases SCRUM is used only for the developing part in the software process, but I want to use it for the whole project (in our case: prestudy analysis, purchase from suppliers, and development.

If I decompose a sprint based on a time limit (e.g. 2-3 weeks each), then the sprint will contain unrelated features as I see it. For e.g. same sprint will contain "prestudy of X", "purchase of Y", "development of Z", etc. Only relation between the features in the sprint will be that they are from the same backlog. The problem is with this case is that it will be hard to find a common sprint goal.

If I instead decompose a sprint based on features, for e.g. one sprint for "prestudy feature X", and another sprint for "prestudy feature Y", then it is easy to have a clear sprint goal for each sprint. On the other hand, this leads to some architects having to work on several sprints in parallel. That is because each and every prestudy require that we involve external consultants. Our architect will more or less just hand over the job to the consultant for the particular prestudy and the consultant will do the rest. So the architect will have time to manage several prestudies in parallel. The problem with this case is that there is a rule of thumb in SCRUM that a person shall not work with several sprints at the same time.

Need some guidance here how to add features in a sprint. If you decompose based on time, how do you create a clear sprint goal? If you decompose on features, do your team work with several sprints in parallel?

Answer 1

A Sprint is simply a release cycle. It's a short-term plan (and, although the Scrum Guide no longer uses this word, I prefer it: commitment) to deliver a defined set of value-adding things to the customer and users. Epics and Stories represent features/functionality and quality attribute of the system.

I'd start to use the idea of Spikes to handle investigation tasks where the objective is to make a decision or learn some information before delivering a value-added capability. Spikes are timeboxed in hours or days. Some teams attempt to fit them into Sprints while others have them live outside of the Sprint, not aligned with Sprint start and end dates. No matter what you do, realize that your team's capacity to deliver functionality will be reduced if a Spike is ongoing. You may opt to put the Spikes into the Product Backlog and/or Sprint Backlog, as well, and prioritize them and have Epics and Stories dependent on their completion.

As far as your Sprint Goal goes, I'm not entirely convinced of its usefulness. As you are seeing, your Sprint could be some combination of delivering functionality (creating software, standing up hardware, etc.) in the form of completing Epics and Stories and learning something new (architectural trade-offs, regulations, languages or frameworks, etc.) in the form of completing Spikes. Based on priorities, your Sprint Backlog could cross-cut many aspects of a software system, making it difficult to write a concise goal. In my view, all Sprints have a goal: to deliver value to the customer and users by meeting your Definition of Done for each completed Story. That value may be in functionality or in an increase in knowledge of the team to make better decisions going forward.

Answer 2

Based on what you've said I simply think Scrum is not suitable for you. You're trying to massage sprints as tasks and they're not designed for that - they're timeboxes to ensure people demonstrate progress regularly. Unfortunately, they're particularly bad when progress cannot be measured in time periods longer than the scrum, or when a task takes longer to complete than the sprint (which will happen with external consultants).

A better approach for you would be a modified Kanban - where tasks are run in parallel anyway. If you assume a task can be 'parked' when sent off to a consultant to allowing more than the prescribed number of in-progress tasks 9ie a parked task doesn't count as in-progress) then I think you'll have a much more manageable (and obviously understandable) process.

There are plenty of other Agile processes out there, I would seriously consider any one of them over Scrum. I would recommend you at least investigate the alternatives.

Answer 3

Thanks for good thoughts, I have been taking them into consideration. What I see is the best option is to stick with SCRUM even if it is not optimal when working with consultants.

@Thomas Owens My experience as scrum master has shown me that when a sprint contains various features that are not really related to each other, it is hard to have good retrospective meetings afterwards. They tend to be vague is my experience.