28
TL; DR
Your question embeds some false assumptions about the linear nature of testing within an agile process. A mature agile team with cross-functional skill sets treats development and testing as intertwined activities rather than as sequential ones.
You should strive to integrate development and testing so that they are not fundamentally separate work ...
12
One approach I have seen work is to initially stub the backend functionality before doing the detailed development work.
These are the steps the team takes:
The backend developer defines an API that the frontend will use for the feature
The backend developer builds a very simple stub that allows the frontend developer to make API calls and get back ...
8
The simplest answer to this will likely be the answer you least like. Don't...
In the last fifteen or so years we have seen an ever increasing level of transparency in the work place. This crosses all industries, all job levels and all work styles. Agile hasn't gained the traction it has because it is the best methods of development ever. Agile has been ...
8
They could be doing a number of things. What they should be doing depends on your organization's Scrum/XP maturity but here are some common items:
QA work - yes devs can QA, whether thats writing new automated tests, upping existing test coverage or reducing test complexity, doing manual testing, or performance/load testing, devs can and should QA. The ...
7
In Team Foundation Server 2013, there are 3 templates available for team project by default
Microsoft Visual Studio Scrum 2013
MSF for Agile Software Development 2013
MSF for CMMI Process Improvement 2013
All of them agile enough to accommodate your needs, but I think the first two are more convenient.
The Scrum template is designed to support the Scrum ...
6
It might be how you're suggesting these changes.
It probably has nothing to do with your position (QA), per se, but more to do with the fact that some new guy is coming in, telling everyone that what they're doing is all wrong (despite not having been around long enough to understand why it's done that way).
In addition, you could even be seen as a threat, ...
6
TL;DR
The original question was tagged Scrum, so my answer will focus on how Scrum expects routine and non-routine changes to be managed. In brief, Scrum embraces change, but encourages the Product Owner to plan refinements for future iterations whenever possible.
By treating refinements as new work, the framework encourages ongoing collaboration between the ...
5
The answers to those questions depend heavily on your company/institution/hierarchy. I think we can only respond in the context of PMI (although I'd love to hear from a PRINCE practitioner or other non-PMI organization).
Work performed as a project coordinator almost certainly qualifies as job experience towards PMP certification (I'm only hedging because ...
5
I would be wary about giving an absolute answer to this because the meaning of a job title can vary hugely from organisation to organisation and sector to sector. In my own sector - digital/software development - I would say that Project Coordinators normally report in to Project Managers who may, in turn, report in to Programme Managers.
In my experience ...
5
I think the reason you've not found much written is that when you get down to the cores of agile, the difference in projects is not all that pronounced. What you want from a project is what really drives the type of implementation, not what you are creating.
Predictable Schedule, Flexible Scope- Use Scrum
Volatile scope, short delivery windows- Use Kanban
...
5
This is based on personal experience, so if it differs from your own, feel free to jump in.
Development - refers to the primary implementation of new projects. Once an initial development project is complete, and the clients/stakeholders have accepted it, then you will typically move into a new phase--either maintenance or enhancement.
Maintenance - refers ...
5
I don't believe it is possible to sort by status changed date. However, given that your requirement is "to have a list of the JIRA tickets that are not moving from one lane to another so that I can intervene on those tickets", you can find all tickets that have not moved in X days. For example:
(status = "In Progress" AND status changed to "In Progress" ...
5
TL;DR
The canonically-correct solution is to put someone with business analysis skills onto the Scrum Team in a Developer role, and then cross-train the whole Scrum Team. Cross-pollination of skills enhances the capabilities of the Scrum Team and the Developers, and builds T-shaped people.
Including someone skilled in business analysis on the Scrum Team also ...
4
TL;DR
Do you think it is worth to put up such a title formalism in place?
No. A title is rarely a unique identifier across bugs, nor is it likely to communicate enough on its own to justify the constraints.
Titles Should Be Meaningful
While I agree that titles should be meaningful, it is very difficult to create a short formalism that could be ...
4
Short answer
Don't formalize. Communicate more often.
Long answer
I think this situation calls for better expectation management / communication. Make explicit what you need from the customer and when, and make explicit when they can expect something back and what.
"emergency" fixes needed overnight
If you mean that the moment the customer finds bugs, ...
4
When I moved into my current team we were in this situation, however I had the benefit of coming in as Application Development Manager. You will face challenges without the authority to make decisions, but a lot of what I suggest below doesn't have to be driven from the top down. To be honest, everything I proposed I asked the team, and got their buy in ...
4
Bluntly the relationship between the project coordinator function and that of project manager is similar to that between a secretary. The secretary has an excellent grasp on the day to day activities of the task, but has never taken responsibility for delivery.
This does not mean that the project coordinator cannot make the step to being a project manager, ...
4
This question raises a big question to me - is this actually a project in itself, or something that will be altered as part of other projects? If the latter, it may not need anything around it other than source control.
Removing the TFS element from this question, Kanban is an agile methodology without time boxing that could be applied. These situations ...
4
I would suggest taking a look at MS kanban 1.0 template. Which is more of a continuous delivery process instead of iteration based approach.
4
Focus on quality and estimates
You identified four problems. Of those, I would view the following two as your main issues (long hours and missed deadlines are likely resulting from these):
Quality of your code is dropping: When the quality is bad, you end up doing a lot of unplanned work. This results in long hours and missed deadlines not to forget the ...
4
The contract type is another factor to consider. A firm-fixed price (FFP) contract can provide you the opacity which is your stated desire. The specification is set in the statement of work or statement of objectives. The product is evaluated for acceptance against the specification. To cut against opacity, the buyer can require "key person" clause requiring ...
4
"Typically for a team of 3 to 4 developers, there would be 1 QA resource"
That's your problem there. There are three roles in Scrum, Product Owner, Scrum Master and Development Team Member. Your Development team is meant to be a multifunctional team working towards the same goals. It's fine to have people with different skills (in QA, in development), but ...
4
Anybody in the team can make suggestions for how the team can perform better, also new team members with a QA background. There are, however, two things working against getting your ideas accepted.
Change is hard. If ideas are not backed with authority (either formal or informal), then the team often finds it easier to dismiss the new idea than to make the ...
4
I would recommend you guys hire an Agile Coach or Scrum Master, at least for a six months period. One of the four parts of the agile manifesto is Individuals and interactions over processes and tools so answering your question, there isn't a right or wrong way of doing thing but a way that the whole team agree on following.
Just to get the ball rolling, let'...
4
If this is the US Federal government, you are in the middle of some serious fraud. This isn't something you fix, this is something you report. Call the whistleblowers hotline and look for a new job.
I think each department has its own process how to do this so you'll need to look that up.
4
I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to ...
4
There are two answers here - the Scrum answer and the my practical answer.
In Scrum, there are three "accountabilities" (prior to the November 2020 revision, roles) on a Scrum Team - Scrum Master, Product Owner, and Developer. A team has one Scrum Master, one Product Owner, and everyone fits into one of these buckets. However, if there are multiple ...
4
I have seen many business analysts work well in Scrum teams.
The three biggest challenges for them are typically:
Reaching a clear understanding of roles and responsibilities with the Product Owner
Adjusting to the just-in-time nature of Scrum - looking to add detail at the latest possible moment
Becoming good at responding to change - taking feedback from ...
3
I hate to be the type of person who says, "It depends" - but, it depends.
I tend to divide things between project-specific concepts and generic concepts. For example, I recently worked on a site which displayed a lot of data in the form of progress bars in two different areas of the site. So, three tickets/stories get generated:
Widget 1 consisting of ...
3
See my comment above; I think the answer is highly localized to the company. I'm going to suggest two levers that could be used, but either of these could be a career ender in your company.
The core of the answer is that you are responsible for project closure, not completion. If the project is going to fail it is in the company's best interest (and your ...
Only top voted, non community-wiki answers of a minimum length are eligible
