Scrum best practices

Hi,

Does anyone have best practices for managing Scrum and Sprints across multiple projects and service requests? Like a master plan and master sprints.

We have capital projects, or major projects, which require TDX project management. Those projects either have waterfall or card wall plans. Projects with card wall plans are typically managed as kanban boards, where tasks (cards) are simply moved from one status to another (New, Scheduled, In Process, Completed).

We also have smaller projects that we create as service request tickets. These tickets often have ticket tasks associated with them.

We have a development team and an operations team, and sometimes both teams will work on tasks within the same project. For example, the operations team may install physical servers, implement network changes, etc., and the development team may configure software, security, etc. While that project is ongoing, they also work on smaller unrelated projects (service requests), such as updating labs.

Our sprints are every two weeks alternating between Dev and Ops. I meet with the Dev team on Monday, we set our sprint for the tasks we need to complete in the next two weeks. The next Monday, I meet with the Ops team, and we set our sprint for the tasks we need to complete in the next two weeks. This cycle repeats. There are often dependencies between the two teams where the Dev team is waiting for something to be completed by the Ops team.

I've created workspaces for each team, and tasks are associated with those workspaces. However, I don't see a way to group tasks into sprints within a workspace. I'm considering creating a workspace for each sprint and then deactivating the workspace at the end of the sprint.

Is there anyone else in a similar situation, and if so, how do you manage this in TDX?

Thank you in advance for your help.

Tags project-management agile scrum
Asked by Jerry Taylor on Thu 4/20/23 11:08 AM
Sign In to leave feedback or contribute an answer

Answers (2)

This answer has been marked as the accepted answer
Brittany Renn Thu 4/20/23 11:32 AM

Hi Jerry, 

Can you elaborate a bit on how you're imagining to group the tasks? You should be able to filter the timeline view of a workspace by dates of your choice, so you could set the dates as the two week sprint span to see tasks created/due/completed within that time span. 

Best,

Brittany Renn

TDX Support

No feedback
I would sure like to do something similar. I have one team, 6 devs, 4 BAs. We work on multiple projects at a time. But, it seems in TDX I can only get a card wall per project. Not a master card wall for the team to work from. Perhaps it's out configuration. But, I don't see how what the OP and I are looking for is possible in TDX. - Cecil Smalley Thu 10/26/23 1:08 PM
It's true that one single card wall cannot cause cards on other card walls to be updated, yes. You *can* have multiple card walls per project though. It will likely depend just on how you make use of those card walls, maybe use a master one for higher-level items, and then develop more detailed card wall for the involved tasks of each of the high-level topics? - Mark Sayers Thu 10/26/23 1:33 PM
Jerry Taylor Fri 10/27/23 8:29 AM

We attended a Converge webinar round table and got very useful ideas. I ended up creating a department-wide project named Technology Department Projects. I have two primary card walls in that project, one for the Dev team and one for the Operations team. Each card wall has four lists, Backlog, In Process, Completed, and On Hold.

We defined what an actual project means to our organization. Anything that meets the following criteria will be a TDX Project. Everything else, such as projects internal to IT will be on a card wall or a service request.

We can then use the backlog manager to get an overall picture of the projects. However, I'm far from having this setup and working the way I would like it to work. But I'm optimistic.

We also use the Technology Department Team to record our time that's not related to a project or a ticket and to record out-of-office time.

Definition of a Project. A work effort may be considered a project if it meets four (4) or more of the criteria.

  • The initiative is estimated to take over 50 hours.
  • The initiative is estimated to take longer than 3 months.
  • The initiative or probable solution is considered to be complicated.
  • The initiative involves unfamiliar technologies, new products, or unique solutions.
  • The initiative will involve more than one department or multiple units within the organization.
  • The initiative has dependencies on other projects or vendors.
  • The initiative has a high impact on other users or impacts a large number of users.
  • The initiative is considered to be high-profile work for the department.
  • The initiative must be delivered within a short or specific timeline.
No feedback