New answers tagged planning
1
I don't have any experience with this use case, but there's a general guideline for datastores that would seem to apply: organize from the perspective of the questions you will be asking when you want to get data out of it.
So, when will people come looking to find things in this tree? What questions will they be asking? What will make it easiest to find ...
0
Every place that I worked had a different standard, usually defined by the Project Office / Project Management Office. Your suggested layout looks reasonable, but without knowing your specific organisation, it is hard to be specific.
Your suggestion combined deliverables and stages into a single structure, so one possible alternative that I have seen is to ...
1
Just to add one component to the mix:
Try something, then fix it when it doesn't work.
This depends pretty heavily on Sarov's answer (if the team doesn't talk, they can't fix stuff), but this is another important component of making Scrum work. For any Scrum team, its first few Sprints are likely to go askew in some way - too much work, not enough work, too ...
1
If you want to plan tasks down to the hour, you should switch the settings of your project file to have duration entered in hours instead of days (You can access this form by clicking File --> Options):
This will allow you to plan tasks down to the hour without the need to use different dependency types (Start-to-Starts or Finish-to-Finish) or worse, ...
1
I'm not entirely clear on the problem you're describing, but I think the way I'd handle it is to make them all dependent on the same task.
#
Task
Depends on
1
setup at client site
2
Transport materials to client site
1
3
prestage kitchen
1
4
construct stage at client site and install equipment
1
5
Final client site pre-check
1
All of the dependent ...
3
Think deeply about when and where the team members need to collaborate and build your approach based on that.
If the individual disciplines are on separate work streams and rarely need to coordinate then your solution is likely to be less like a traditional Scrum team. Possibly a Kanban framework would be more appropriate and knowledge sharing where it may ...
3
Talk.
(I was so tempted to end my answer at just that one word.)
Seriously, though - your problem is that you don't have a single, cross-functional Team. You have four teams that call themselves/are called one team.
Your developers (and they are all called 'developers' in Scrum parlance) don't need to be generalists, but the goal is still for them to become ...
0
Many actual teams, quite without realizing it, are "lone wolves, in a pack." Their most natural mode of operation is therefore "pantsing" – as in "do it by the seat of yours."
And if you're not careful, your own role becomes just that of a "supervisor." Bad move.
A few ideas that have worked well for me have been to, ...
Top 50 recent answers are included