5

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?

  • Can you define what you mean by "prestudy of X", "purchase of Y"? Are you asserting that learning something new or making a purchase are part of your product or sprint backlog? – Thomas Owens May 25 '16 at 12:15
  • It is prestudies like "investigate what type of authentication we need to be in line with regulations", or "investigate the need of microservices for our system". Yes, I am asserting that. – Kran May 25 '16 at 12:23
4

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.

1

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.

  • Trying to time box tasks out of your control is a fool's errand. It just creates noise on the Kanban board and tends to be inaccurate. It can also create ill feeling because devs are being held to their estimates (yes, I KNOW they're not supposed to be since they're estimates but it happens) while tasks in progress by 3rd parties are allowed to drift. – Robbie Dee May 27 '16 at 8:12
-5

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.

  • 3
    This looks like a comment, but you added it as an answer. If you are responding to somebody's answer, you should add a comment to that answer. – Eric King May 25 '16 at 19:01
  • Insanity: doing the same thing over and over again and expecting different results - Einstein. – gbjbaanb May 27 '16 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.