Skip to main content

How to handle other tasks than regular coding

Last post 05:06 pm February 7, 2024 by Daniel Wilhite
10 replies
10:42 am January 30, 2024

Trying to settle an internal discussion on how to handle tasks that are not strict development (coding). 

This would include, but is not limited to

  • Design
    • System Architecture
    • High-level and low-level design
    • UI and UX
    • Database design
  • Testing
  • Documentation

On member of our team has an understanding that only coding tasks should be handled by the team in the sprint. All other types of tasks are considered as something which must be handled outside the sprint. 

To me this seems a bit odd, as I feel both testers and ux-resources should be part of the team. In addition to that would make scrum a method only to be used by developers and by software firms.

Can anyone shed some light on what Scrum really says on this?


09:37 pm January 30, 2024

There's nothing that says that the work must be coding. Within the Scrum framework, I see two places where work is done.

One place where work is done is Product Backlog refinement. Refinement, according to the Scrum Guide, "is the act of breaking down and further defining Product Backlog items into smaller more precise items". In my experience, some level of architectural and design activities are helpful to understand what those "smaller more precise items" are. Understanding the desired user experience can also help the team understand what is necessary. Finally, if you're following test-driven development (or acceptance test-driven development) practices, you may start to write test cases from the description of the work, so this could conceivably be done as part of refinement.

The rest of the work is done within the context of a Sprint and delivering the work. Even after refinement and any design that is part of that activity, more detailed design will likely need to be done as part of implementing. The team's Definition of Done should also be inclusive of ensuring that the work, after it is integrated, is usable by stakeholders. This would include testing, documentation, and other activities that may be required by the customers, users, or the context in which the system is developed and used.


12:45 am January 31, 2024

You're understanding is correct, testers and UX designers are considered to have Developer accountability in Scrum. Developer accountability does not strictly mean software developer or computer programmer.

If your Scrum Team needs UX design work, testing, and documentation before the Product Backlog items are considered 'done' (in other words useful, valuable, potentially releasable), and can't complete that work in a Sprint and have to do that outside of a Sprint, they are missing what Scrum is all about.


03:13 am January 31, 2024

All other types of tasks are considered as something which must be handled outside the sprint. 

There are no gaps between Sprints, so all work must be happening in a Sprint somewhere. This includes refining work so it is ready for future Sprints, and the design, testing, and documentation needed to craft a Done Increment this Sprint.

Anyone whose industry is needed to create a Done Increment of usable quality is one of the Developers on the Scrum Team, whether they be a programmer, designer, tester, or a technical writer.


07:25 am January 31, 2024

Thank you for your comments.

This is more aligned with how I understand scrum.


07:13 am February 6, 2024

A follow up to my intial question. 

On our team we often have "design" PBIs that only have a specific design as it's output. We will then have the implementation of that design as another PBI in a later sprint (usually the next).

I see that you could argue that the design PBI is refinement and should be done outside the sprint, but could you also argue that the design itself puts value to the business so it's a valid PBI?

Our developers do all the work related to design and implementation, so it's not a question of different resources doing the refinement.

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?


07:54 am February 6, 2024

If it takes longer than one month to frame and perform an empirical experiment, then the validated learning loop has become attenuated. You're doing something else, and the outcomes which might be obtained from the Scrum framework can no longer be expected.


11:17 am February 6, 2024

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?

Yes, because when the design PBI is done, no value which can be used by a customer has been created. Out of that, the design is as important the implementation, tests, documentation,... for the value creation. 

No, because Scrum does not mention how to organize the work. The question is, why do you want to split the design from value creation. Is it for reporting what the team is doing/for collecting ideas/...? 


01:03 pm February 6, 2024

On our team we often have "design" PBIs that only have a specific design as it's output. We will then have the implementation of that design as another PBI in a later sprint (usually the next).

I see that you could argue that the design PBI is refinement and should be done outside the sprint, but could you also argue that the design itself puts value to the business so it's a valid PBI?

Our developers do all the work related to design and implementation, so it's not a question of different resources doing the refinement.

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?

 

Yes, splitting design and implementation into different Product Backlog Items is inconsistent with Scrum. A Product Backlog Item that only results in design often doesn't add value to stakeholders - that is, they cannot use your design to help them with whatever problem your product is designed to help them with. The analysis and design activities are only directly useful to the people doing the work, not to the people receiving and using the product.

It's not a clear split in a way that you can say that all design is part of refinement and all implementation is not. There's a fuzzy line that's very context sensitive.

Refinement is about breaking down Product Backlog Items into smaller, more precise, more detailed items. The result of refinement is a Product Backlog Item that is ready for a Sprint. The minimum criteria for a Product Backlog Item to be ready is that it can be done within a Sprint, but the team may add other criteria or expectations. In my experience, what the team considers necessary is related to the risk tolerance of the organization and stakeholders. When the risk tolerance is low, the team needs to spend more time in refinement activities to reduce the chances of other work emerging. However, when the risk tolerance is high, then the team may be able to tolerate unexpected work emerging and the likelihood of not being able to complete Product Backlog Items or missing their Sprint Goal.


09:06 am February 7, 2024

Would splitting design and implementation (coding) in different PBIs and sprints conflict with the Scrum methodology?

This would go against Scrum if you do only the design PBI in your first sprint (and nothing else). As per Scrum, design/architecture should emerge along with a valuable increment. But I have come across some cases where this happens like in a Sprint there is no work for the UI designer and hence to keep him occupied some design related PBI is picked up and worked up (splitting design and implementation from an item in the product backlog). This is fine if you have other PBI's which deliver value in the current sprint. Infact UI mockups can be shown in the sprint review to get early feedback. In the next sprint your design PBI (from older sprint) and the corresponding implementation PBI would together produce value.

Just my thought :). I would like to hear from others too on this.


05:06 pm February 7, 2024

I agree with the folks above.  Typically design is either done as part of refinement or at the time of the solution being built.  But I will add one small caveat. 

I have had teams use what they called "Spikes".  These were research/experimental efforts to gain more insight into the problem that they were trying to solve.  They were typically created when during refinement discussions, the team still had some answers around the problem and whether it could be solved.  So they would create a "Spike" in the Sprint Backlog, add a timebox limit on how much they could send working on it (i.e. 4 hours), and then do that work as part of the Sprint.  We used these sparingly but the team found them useful for being able to focus.  By putting them in the Sprint Backlog, it was transparent to anyone that they were directing some time away from the Sprint Goal for a specific purpose. 

I am not sure if your design PBIs are like our Spikes but wanted to add this little wrinkle to the conversation.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.