I am trying to follow scrum framework as much as i can but i am facing some confusion. I like to know what are the standard guide lines for a sprint. I am designing the sprint but i am not sure to get to a concrete value in terms of hrs/day. And what is the standard practice ? Should i also lock meeting hours, deployment time in a ticket ? What happens if an urgent hotfix comes up from a client ? It does not happen very often but what to do in such circumstances. Thanks
I am designing the sprint but i am not sure to get to a concrete value in terms of hrs/day. And what is the standard practice ?
Scrum doesn't address this, but one of the 12 Principles of Agile Software Development states that the developers (along with sponsors and users involved in the development process) "should be able to maintain a constant pace indefinitely". How many hours per day and days per week can you development week maintain constantly? In the United States, where a 40 hour week is typical, that's what we use as a baseline. But there are ways other than hours to estimate and plan or forecast work being done or effort expanded.
Should i also lock meeting hours, deployment time in a ticket ?
Scrum or the other Agile methods don't care about tickets. Scrum has the notion of a Product Backlog Item, which is a change to be made to the product in a future release. Depending on your project management or issue tracking tool, maybe it makes sense to put in tickets for deployments. I typically use a calendar for the different Scrum events and project events (like deployments) and share that calendar to the team. I probably would not use tickets for regularly occurring events - since everything is happens on a cadence and is timeboxed, the time spent in Sprint Events should fall out in the estimates. Any other organizational meetings should, as much as possible, be set up in a cadence that lets the team estimate. One-off working meetings should be a part of getting the work done.
What happens if an urgent hotfix comes up from a client ? It does not happen very often but what to do in such circumstances.
There's a recent Scrum.org blog post on handling unplanned work in Scrum and aligns with what I've usually done. 40% of your Sprint Backlog is work that adds value but doesn't directly contribute to the Sprint Goal. If there's a critical issue, you have 40% of your capacity to trade out to include it. However, this requires that you have a good ability to forecast how much work you will be able to take on in a Sprint and the team to not bring too much work beyond their capacity into the Sprint.
Hrs/day is an irrelevant measure in a scrum framework. Trying to come up with one is hard because you really aren't supposed to. In scrum the main units of time are the sprint itself and story points. Story points are intentionally an indeterminate amount of time, the important number is velocity which is based on length of sprint. You forecast when things will get done by looking at your backlog and using velocity, if you have a poorly developed backlog or work comes in unexpectedly then forecasts will be inaccurate, but nothing else will make them accurate either. Once you have a velocity you can tweak it a bit to handle the irregular things like vacations, quarterly meetings, holidays, etc.
In the case of urgent work that comes up during a sprint that has to be done in that sprint, the process is mostly the same. You write it up and if it's urgent try to get a quick estimate of points, then you identify a number of stories with the same points to remove from the sprint to put that item in the sprint. Part of the importance of pulling out stories from a sprint is to help determine if something really is urgent. Generally there are a few stories in most sprints that can be easily removed to make room for unplanned work. It's also important to keep track of how much work per sprint ends up being unplanned, if it's half or more then Scrum is probably the wrong process to follow entirely, and you should consider trying something like Kanban. Personally I would suggest at least considering a different process (or shortening the sprint) if about one third of a sprint is regularly unplanned.