Scrum best practices

Nobody who is using scrum with Clarizen is willing to give suggestions?

Sorry Peter, we are discussing this internally with our best Scrum-master and will get back to you later today.  Those are a lot of questions! =)

Sorry for being impatient - I am just so excited to get started properly with Clarizen :-)

Thanks for your patience, I can at least start by giving you some of the answers:

Now, we want to set it up with all artefacts, RBL, team board, burndown, etc. I have installed the app and got the board enabled. However, I have some questions for best practice:

• Since I want all my developers (with a team license) to be able to view a team board, the actual iteration needs to be a Task. It is impossible to make the top level (under which all tasks in the sprint backlog are placed) a Milestone or a Project, because it is impossible for these resources to navigate to this level and open the team board. Correct? I actually believe this is a flaw in Clarizen that you need to hold a manager license in order to participate in a scrum team.

Josh: You could use milestones and assign people as resources to that milestone, but they will have very limited editing permissions. In the future we are planning a feature that will allow you to easily assign multiple managers to work items (without having to utilize the current hierarchical permissions).

• Ideally I'd like Work to be fixed so developers can see the original estimate in the Team board without the ability to update Work - as a means to remind them of original estimates. BTW we update progress for Remaining Effort and Timesheets

Josh: Work is really designed to be used as an estimate, so I think this will work out perfectly… especially if you are using Remaining Effort and Timesheets. You even have a “Work Variance” field that will give you the difference between your Work and the Actual Effort. Resources are not able to change the work field without managerial permissions, so you do not have to worry about this field being modified by another other than a manager, project manager, or super-user. I would also make sure your projects are set to “Fixed Work” as opposed to “Fixed Duration.” If you are curious about the differences between the two or how to set this up, I would recommend hopping on either our Q&A Forums or our Power User Training webinar over at http://webinars.clarizen.com.

• Why is there a Team board both in the Properties section (top) and in the Work plan section? I don't guess there is any difference?

Josh: The one in the properties section will launch on the overall project while the one in the work plan will run on the selected work item. For example, if you wanted to open up a team board only for a single sprint, or you just wanted to look at the backlog, you could do this by selecting that object in the Work plan and using Utilities >> Team Board. The one on top will always open for the entire project.

(BTW, can you please make the text editor field a bit bigger in the forum? The iframe definition is too small for the editor in width and I'd like a height of at least 200px)

Josh: I completely agree! I believe this is related to a Zendesk bug, will re-escalate this.

Josh: You could use milestones and assign people as resources to that milestone, but they will have very limited editing permissions. In the future we are planning a feature that will allow you to easily assign multiple managers to work items (without having to utilize the current hierarchical permissions).

Peter:  But although I assign them as resouces to a milestone, since they cannot navigate to it (click on it/have it show up in their views [or even navigate/click on it in the project path all at the top beneath the tasks names]), they cannot open the Team board for all the tasks in the sprint since the Team board shows tasks "below" your current WI. So, as I see it, the Milestone idea (which would be the natural way of doing it IMO), is impossible with Team Member licenses. Unless I am missing something in your reply.

Josh: Work is really designed to be used as an estimate, so I think this will work out perfectly… especially if you are using Remaining Effort and Timesheets. You even have a “Work Variance” field that will give you the difference between your Work and the Actual Effort. Resources are not able to change the work field without managerial permissions, so you do not have to worry about this field being modified by another other than a manager, project manager, or super-user.

Peter: However, if we plan to let developers break down user stories into tasks (which I guess is the normal way of doing it), they need to be WI managers for the users stories in which case they can change Work. I'd like to show them some reminder of what the original estimate for the user story was. We can use the budgeted work for this but it is not used for any calculations or rolled up.

Thank you for your anwers.

A few additional answers:

• What is the best practice for working with resource assignments? I guess I should add all front end developers to all front end tasks and all back end developers to the back end tasks? Maybe all to all? Otherwise resources cannot move items in the Team board.

Josh: You should assign whomever may need to move that task in the SCRUM meeting (the person moving the task needs to have a role). If you have one person that is in charge for moving all of these tasks as part of your daily SCRUM then that person should be a project manager or manager in the project or a super user.

• What should I do regarding start and end dates? We will be working with a burndown chart but I would also like to be informed in the higher levels of the hierarchy if the progress is at risk. Manually filling in Start Dates and Due Dates on each task is tedious, especially since a task may have Work 8h and Duration 10d (we run 2 week sprints). You need a lot of fiddling around with dates.

Josh: What we recommend is setting the start date to be the start of the sprint and the due date to be the end of the sprint.  That way if you are below the ideal burndown line in the burndown chart, you know the tasks will be done by the end of the sprint.

• I have changed it so the EE fields are rolled up at the top level which would help calculating how filled up the sprint backlog is but RW in these fields are not to be used in actual progress tracking, right? Only Remaining Effort is used here.

Josh: Which RW field are you referring to?  The Remaining Effort should be filled by the team to indicate their remaining work and this does roll up.  

As for the team member licenses, I see your point now. Perhaps it might be worth it to upgrade those to full? The cost difference is marginal but there is a lot more functionality and flexibility in those licenses.

Regarding Budgeted Work, we can make this a field that is used in calculations.  We have a very robust customization engine and you can create your own rollup-fields, formulaic fields, and workflows (ex: automatic email every time something goes over budget sent to the PM).  The Advanced Q&A is the best place to get help with adding these fields into your account and we should be able to accommodate just about any scenario you can think of.

Hi Josh

Thanks for your answers. A couple of comments:

• If you have 40 tasks in the sprint it's a bit tedious to set the start and end date to all. There is no way to do this to all tasks in one go is there? I cannot seem to multi-select the date fields for pasting.
• Sorry, the Remaining Effort field is not in any way linked to the FE/BE/QA EE fields - which are added to the Work field. So progress tracking (Remaining Effort) is the used for tracking remaining work. We have it set to individual reporting - but this does not work in the team board it seems?
• You're right regarding some custom action can be made for budgeted work roll-up, it just seem less than ideal it's needed (and Budgeted Work doesn't roll up as standard). But I will think about this.
• Licenses: It's your software, but I think that it's too much to demand all developers have a PM license in order to open a scrum board using expected artefacts - but not to worry, I found a way it works. :-)

Thanks again for the answers which were pretty much as expected.

• If you have 40 tasks in the sprint it's a bit tedious to set the start and end date to all. There is no way to do this to all tasks in one go is there? I cannot seem to multi-select the date fields for pasting.  Josh: Good news here, you can indeed do multi-cell copy/paste.  You just need to copy one instance of the individual cell and then you can select multiple date cells (in the same column) and past to all of them simultaneously.  I would recommend using Ctrl+C and Ctrl+V here.
• Sorry, the Remaining Effort field is not in any way linked to the FE/BE/QA EE fields - which are added to the Work field. So progress tracking (Remaining Effort) is the used for tracking remaining work. We have it set to individual reporting - but this does not work in the team board it seems? Hmm, I would consider this a bug.  Can you open a ticket for this up at the top (individual reporting does not work in the team board).
• You're right regarding some custom action can be made for budgeted work roll-up, it just seem less than ideal it's needed (and Budgeted Work doesn't roll up as standard). But I will think about this. Josh: its an easier customization than you would think. Again the Advanced Q&A is a great resource here and we should be able to hit just about any scenario that you can come up with.
• Licenses: It's your software, but I think that it's too much to demand all developers have a PM license in order to open a scrum board using expected artefacts - but not to worry, I found a way it works. :-)  Josh: this one is out of my wheelhouse, but I am glad that you have a solution!