I'm not going to address your math directly, because it's a solution for Y in an X/Y problem. Specifically, how long it takes to complete your current backlog should be a function of your current lead and cycle times, not an invitation to resize your queues or attempt to crash the project by adding additional resources.
What you really ought to do is ...
Projects change, products evolve, and team composition often needs to change along with them. Slack and reasonable levels of idling are the cost of doing business in an agile framework, but don't be afraid to add or remove people from the Development Team when it measurably benefits the project.
Analysis and Recommendations
You may have a ...
A similar situation happens with the developer-tester relationship. In simplified terms, at outset there is nothing to test and everything to develop, but at the end of the project the opposite is true.
There are several common strategies to deal with this:
Blur the role boundaries. For example, developers do some testing at the end.
Have the team perform ...
There are a few things to think about here.
Firstly, how do you define your priorities? If they are only defined at the individual team level then it makes prioritising requests from other teams challenging.
Ideally where work is shared there needs to be a clear, top-level prioritisation in place so that is easy for teams to know what they should be ...
Hold the event daily, even if you don't use the whole time box allocated for the meeting. Don't skip it routinely, even if you think you have good reasons. Doing so may not bite you right away, but it probably will eventually.
If you're not finding value in the Daily Scrum, it's likely because the team isn't really performing just-in-time (JIT) ...
One of the advantages of having such a small team is that, indeed, the people in the team are able to communicate freely throughout the day. A lot of the daily stand-ups might thus often end very quickly and may look like they are a waste, but they can still have a purpose even in a small team like this: to provide extra focus.
The daily standup allows ...
In Agile it can be useful to think of individuals having a capability rather than a role.
Jill has a capability to do development work
Sam has a capability to do testing work
Helen has a capability to do both development and testing work
If our team is full of specialists who can only do one thing, then when we bring work into a sprint it can ...
The question to ask yourself is:
What information do we want to get from a burndown?
Different teams will use the burndown in different ways.
A popular approach is to burndown on completed stories. This gives an indication to the team if they are 'back-loading' the sprint, i.e. that stories only get done towards the end of the sprint instead of ...
Work is Done or Not-Done
Scrum does not require the use of user stories, story points, or burn-down charts. They are commonly used as a best practice, but it's important to understand that they aren't framework requirements.
With that said, widely-accepted agile frameworks generally treat work as either done or not-done. Product and Sprint Backlog Items ...
What is the definition of work done in Scrum
Work that satisfies the Definition of Done, which is defined by the Team.
The problem with this is that work being closed on a daily basis is not shown on the Burndown chart
This is the correct behaviour. From Scrum's perspective, an incomplete story provides zero value, so the burndown shows zero progress.
The Scrum Guide states a few things about the Development Team - it is "self-organizing" and no one can tell "the Development Team how to turn Product Backlog into Increments of potentially releasable functionality", that there are "no titles for Development Team members, regardless of the work being performed by the person", there are "no sub-teams in the ...
It is not the responsibility of a scrum master to do all non-coding tasks.
Can this task be put on one or more tickets? This actually looks like two tasks:
create new server (List in ticket's Definition of Done: approval gained; get requirements signed off by IT&S; server provisioned; server requirements validated as correct; ...)
further application ...
Facilitate Communications; Don't Proxy Them
In your specific example, the Scrum Master should function as a communications facilitator, not a proxy for the team. The Scrum Master often functions as a switchboard operator by:
Helping team members to identify points of contact outside the team for collaboration and refinement of Product/Sprint Backlog Items.
You're right that the Scrum Guide is rather vague when it comes to how involved the Scrum Master is when it comes to removing impediments.
Personally, I believe that the Scrum Master should, as much as possible, be hands-off for how the team works. The Scrum Master is a single individual. In some organizations, this person may be working as a Scrum Master ...
Well, the Scrum Master should help with impediments. You have given no indication that this is an impediment. What makes the email to the head of IT an impediment, unsolvable by the team themselves?
The Scrum Master is not the teams errand boy. If the team cannot do it themselves, then the Scrum Master is their escalation step.
If it is sufficient to ...
To me it sounds like there is too much going on at once. Instead of trying to figure out how to structure multiple projects at once and organize everyone into cross-functional meetings, etc, I would instead try to figure out how to create more focus.
Here's the thing: people do not multi-task well. The more they are required to context-shift (for example by ...
Don't bring people to projects, instead bring work to people.
Form a team with a good mix of skills and then have them pull work off a backlog. It doesn't matter which projects the work is from, just that they have the capability to do the work.
Prioritise the backlog so that work items for more important projects get done first.
The advantages of this ...
My suggestion would be to pick a 'theme' for the fixes that is important.
This sprint our goal is to improve the user experience with search
The focus for this sprint would be the defects relating to search. There may be other types of defects being worked on, but the team knows that it is the defects relating to search that are key to the ...
If you are using Scrum, then you must have a Sprint Goal and produce a potentially releasable Increment by the end of the Sprint timebox. These are things that are core to the Scrum framework.
But you don't need to use Scrum. Perhaps Scrum, as it's defined in the Scrum Guide, doesn't make sense for your team as you are focused on support and maintenance. ...
Due to the nature of most Agile development, the details of a given piece of functionality can change over time (in fact, if this isn't true, you aren't very agile). Therefor, what is on a given card in your backlog is just a description of that point in time, making it ill-suited for long-term documentation. Further, documenting too much in cards can lead ...
I have successfully kept the "issues" in Jira and then used Confluence for the type of documents that you are mentioning. My recommendation would be to keep your documents in a more appropriate system, for instance Confluence.
Sure any kind of documentation system would do. Both Jira and Confluence are from the same provider, Atlassian.
Is a mid sprint check-in/catch-up a good idea?
For the situation you are describing, no.
I wonder sometimes do they actually bring up impediments, concerns or issues.
You are worried that people don't bring up impediments or issues at the daily standup. But the meeting you are proposing to have mid sprint has the same purpose as the daily standup ...