To your overall question, while Scrum can be applied in most projects, it is not necessarily the best approach for some projects. That said, it is well suited to complex problems that require discovery of the solution and adaptation to new information. Your project sounds like exactly the kind of project Scrum was designed to tackle. However, you raise some ...
Embed Skills, Not Individual Roles
Ideally, all product development resources should be intrinsically part of the Scrum Team. That makes any team member developing the product a co-equal “Developer,” regardless of variant skill sets within the team.
A product-design focused Developer should be treated as an integral part of the Scrum Team, rather than a ...
Management by surprise.
One thing you might try is each time your boss comes in with new urgent tasks you ask him: "Which of the tasks we have already agreed on should I drop in exchange for the new one?"
Is Scrum actually suitable for all kinds of projects?
Like with many things in the software industry, Scrum is not a silver bullet. It works nicely for some types of projects, and less so for others. I've often seen the Cynefin Framework mentioned when trying to identify projects types where Scrum might be used, so maybe have a look at it and see under what ...
There are two components to A/B Testing. The first is the "why". The second is the "how".
I'll start with the "how" first. This is the implementation. This is the technical details that developers should handle. Depending on what exactly you need to test they might need to configure something, make a small change in the code, or make a big change in the ...
I would strongly suggest you ask the team.
The team understands the domain, the way they work, the personalities involved and the nature of your organisation. They are in a much better place to determine the team structure than anyone outside of the team. This is what we mean when we talk about self-organising teams.
Also, don't be afraid of making the ...
How is your 'rejection workflow?'
If you need a workflow to handle rejected user stories, then you have a problem.
Normally, a user story being rejected should be an exception; someone misunderstood something, someone made the wrong assumption, someone failed to communicate... it happens. Nobody's perfect. But when it happens it's something that it's ...
The Scrum framework can usually be adapted to any product or service that can benefit from time-boxed effort and incremental delivery. That doesn't mean it's the best fit for every project, but the original question does not describe anything that can't fit into a Scrum implementatation.
The question, as currently constituted, ...
Adding a bit to Daniel's excellent answer.
all the work is deeply technical and has no user facing consequences
But you also say:
focused on improving the performance of the product as a whole
I can think of two reasons why you might improve the performance of the product:
To improve the user experience (quicker response times, etc.)
What you need to do is some Project Management.
Start with a Task List - a simple Excel Sheet will do. or use an online tracking system like Trello. You need a few columns:
Priority - a numbered list where the top item is always #1, the second #2, etc.
Task - a short description
Duration - how long it'll take. If you standardize to hours or days, you can ...
By this brief description, it sounds like you company is busy, has a strong client base and healthy demand; it sounds like your company is staffed lean and mean; and deadlines are not a critical success factor, i.e., your clients are still providing a healthy demand despite their work being delayed. Perhaps your company is bringing in a healthy profit, as ...
Disclaimer: This comes from my experience on the financial sector. It may or may not be applied to other areas, as some expressions are very common on specific industries but not used in others.
As described by this hbr.org article, firefighting is the working "model" where
Managers and engineers rush from task to task, not ...
Your current process contains a large set of agile anti-patterns. Some of these process dysfunctions include:
"Testing" divorced from a Definition of Done (DoD).
Lack of test-first development.
Sequential (rather than collaborative) activities.
Treating changes (other than DoD gaps) as rework rather than new work.
While JIRA's ticketing model is ...
When you receive a bug report, it needs to be triaged. The workflows that I use tend to look something like this:
Review the bug report and confirm that it truly is a bug. Some people who report issues may not be aware of the intended behaviors of the system. The issue reported could be acting as designed.
Assuming that the issue is a bug, check the quality ...
To put it bluntly, from a commercial perspective people only care if you deliver the project they requested within the time and budget you promised. I have intentionally chose the word "promised" because if you don't do a proper job at communicating things, people that don't understand how the project is built will take things as a promise. And when the ...
From the looks of it, you currently don't have a team. You have a group of developers presumably working in the same office. To turn them into a team, you need to get them to take collective ownership of the unsliced work-items that provide value to the business.
A few suggestions in that direction are
Hold a retrospective with all team members about how ...
The Product Owner doesn't need to care about Tasks.
You should not be creating them. You should not be looking at them. You should not care about them.
You create and prioritize the Stories. The Team then creates Tasks and Sub-Tasks. The Team must update Stories when they finish working on them.
There is no such thing as a 'half-finished Story'. A Story ...
Simply putting, you can't.
What is a Service Level Agreement?
A Service Level Agreement, as the name says, is an agreement stating how a (already existing) service is going to be provided.
SLAs are useful to set the minimum acceptable service levels against specific metrics or Service Level Objectives, such as response time (how long users will have to ...
The "vague IT idea" is what you need to focus on. The project--how you set it up, the development method you use, who you hire for it--is irrelevant and thinking about it now is premature. Look at this way: you wake up one morning and decide it's time to modernize your kitchen. That's all you have at the moment is that you want it to change. Would you be ...
The first step is generally validating the idea - fleshing it out from "vague idea" to something that starts to identify the benefits that you expect to get from the project. In such a step, this is no different from any project - it isn't unique to IT projects. Once you have an idea of the benefits, you can start to think about the project methods, ...
For any technology project the most important first step is to get the right expertise together as a team and then let the team (which will grow over time) develop their plans and ideas. Team before plan, not plan before team.
Scrum is the most popular framework for software development projects and is also used for many other kinds of work. Ultimately the ...
Having a productive development team and getting the right kind of engagement with stakeholders are what matter. If those are in place then the team can decide for themselves what documentation is useful. A single answer is not going to suit all projects and the same documentation won't necessarily be appropriate for every situation on a given project.
and welcome to the community!
I can tell you two or three pieces of advice from my own experience:
Involve in the estimation things that are time consuming and indirect part of the project: Meetings, planned unavailablity of the employees, quality feedback loops, potential integrations with products that are outside of your scope of action, etc.
Don't rely ...
Scheduling software development is somewhat of an art.
Because you're scheduling the unknown. If something identical was already coded then why are you redoing it? If something is slightly different, then there's no way to know how long it will take.
Besides, developing SW is more more than simply coding in C# (in your case). As I wrote on my blog ...
Ask Your Instructor
The problem with tests, especially academic ones, is that only the test developer knows why they think a given answer is correct. In a school context, the only way to know for sure is to ask your instructor.
All the terms you can choose relate to how activities are measured, rather than defining how the two tasks interrelate ...
What’s the relationship between the test planning activity and the testing activity?
The answer should be:
C. Finish-to-Start (FS)
The test planning activity needs to finish, in order to start the testing activity. The highlighted test response might be wrong. It happens.
Whether you're dealing with a project or ongoing operations, a service level agreement should focus on time boxing anticipated activities. Fully-knowable activities can have clear time-box boundaries, while others will simply specify cycle times or communication intervals for longer-lived or unanticipated issues.
Focus on Measurable Outcomes Like ...
I found "state of perpetual emergency" used in multiple contexts to describe this. An article that I recommend that describes this in the context of software development is "Catch the Pig!".
Ask: "Do you think that there will be a day any time soon that is less busy than today" to get work done? So: "...
It is sometimes misleading to have a "manager" title without having real-life experience in project management. Even if it is not stated in your title, if you can show and materialize your past experience in either one of the five main process groups, then PMI will not worry about the lack of a "manager" title.
You're good to go. All the best.