Hot answers tagged

15

There is no planning or pre-planning phase in Scrum. I guess you are referring to Backlog Refinement and/or Sprint Planning (sprint planning is a relatively short time-boxed event and definitely not a phase). Backlog refinement and sprint planning are complementary activities when it comes to helping developers understand items on the backlog. Sprint ...


13

Sutherland decided to make the meeting at most 15 min long. In his own words: [...] the meeting couldn’t last more than fifteen minutes. We wanted it to be crisp, direct, and to the point. If something required further discussion, we noted it and met further after the daily meeting. The idea was to get the most actionable and valuable information in the ...


10

A resource manager as a organiser of day to day productivity has no place on an agile team. We know why they don't belong, it's in your question. They're trying to optimise things that oughtn't to be optimised. It's counterproductive. It could be possible that this "resource manager" is more strategic role than it sounds. For instance, at a staff-...


8

There is no 'Resource Manager' role in Scrum The question that you are quoting has the 'scrum' and 'scrum-master' tags. How do I manage development with testing and get proper reporting in JIRA? So, I am answering this question in the context of Scrum. Scrum has only three roles: Product Owner Scrum Master Dev team In addition, as @todd-a-jacobs has ...


7

If the role of Resource Manager in your organization is seen as maximizing measurable activity instead of produced value, you've got a serious problem. You're going to create more waste by keeping people busy on things that can't contribute to value at that time. If you look at the QA situation, the time in a sprint when final QA is being performed (and thus ...


7

Doesn't really matter. Just be consistent. Scrum (I'm assuming you're using Scrum, given the 'Product Owner' tag) doesn't differentiate between bugs and user stories. It really just depends on how your specific business wants to track things. More than just your testing failed. Generally, by the end of the Planning Meeting, the entire Scrum Team should have ...


6

Here's a more psychology-focused answer. Agile decreases certainty to increase delivery speed of features. This trade-off means that you will never be 100% certain about what is required to develop a specific feature. (If you were 100% certain, it would be waterfall!) This necessarily means that estimates are less precise and more likely to be incorrect. A ...


5

This means you are facing an issue in Backlog refinement. There is another thing that you can do - a spike. Depending on how critical it is, you may assign 1-2 days at max. Honestly, the issue that you are facing seems more technical than related to planning. If I am not wrong then you would be delivering a potential shippable increment at the end of the ...


4

The reasoning behind the 15 minute limit on daily scrum meetings is, as Bogdan points out, that you should never need more than that to achieve the purpose of the meeting, which is just a daily "sync" to keep everyone up to date on who is working on what and check to see if anybody needs to co-ordinate with anybody else on any of the details of ...


3

A common theme in Agile Software Development, and especially in Scrum, is the idea of a cross-functional team. There is no concept of an engineering team finishing something on Friday afternoon and then handing it off for testing later. The team, as a whole, does all of the design, development, and testing necessary to complete the work. This doesn't mean ...


3

Think deeply about when and where the team members need to collaborate and build your approach based on that. If the individual disciplines are on separate work streams and rarely need to coordinate then your solution is likely to be less like a traditional Scrum team. Possibly a Kanban framework would be more appropriate and knowledge sharing where it may ...


3

Talk. (I was so tempted to end my answer at just that one word.) Seriously, though - your problem is that you don't have a single, cross-functional Team. You have four teams that call themselves/are called one team. Your developers (and they are all called 'developers' in Scrum parlance) don't need to be generalists, but the goal is still for them to become ...


3

TL;DR You're conflating engineering and architectural domains (and especially source code management tooling) with business and project management concerns. There's no direct mapping between product increments and merge requests, especially in large or complex systems. Think of a vertical slice as the thinnest piece of coherent, full-stack, multi-layered ...


2

I agree with the earlier answers, but wanted to add a point from the Agile Manifesto that is also backed by research evidence: "The best architectures, requirements, and designs emerge from self-organizing teams." So the short answer to your question is, "Yes." As a coach, I suggest that your role is simply to help the team members ...


2

There is something that needs to be done for the product. You can convey that information no matter what the ticket type is. Scrum doesn't say anything about stories or bugs. It just has a Product Backlog Item that will become a Sprint Backlog Item. In the Scrum framework process is left up to the people doing the work to decide. So I will say your team ...


2

Focus on how to prevent this from happening again As pointed out by others, if calling it a bug is contentious, call it a story. That is the easy part. Also, as pointed out by others, I recommend that you focus on how to prevent this from happening again: Have you discussed this in a retrospective following the discovery of the issue? What ideas did you ...


2

As a rule, try not to differentiate bugs from other stories. What matters is what you want to do about the issue in question and what priority it has. The development team should feel free to label things as a bug if it helps them but that kind of label can be contentious so it may be better simply to label everything as a story.


2

Does it really matter how you classify it? Regardless of if you call it a "bug" or a "user story", the end result is a change to the system. In some environments, maybe it does matter, but in others, it may not. If you don't need to make the distinction, then I would eliminate it entirely. If you do need to make the distinction, I'd ...


2

I think you may be asking the wrong question. In my experience, it doesn’t work - still, tasks cannot be fully developed and tested in one sprint. From a scrum perspective, I'd say the key question may actually be "Why can't tasks be fully developed and tested in one sprint?" Have you brought this question up in retrospectives? Have you tried the ...


2

The safest answer for any software development work is to start and continue incrementally (doesn't have to be Scrum though). There are some bigger questions implied by what you have said. It's frequently said that "rewriting" an application is one of the things you should never, ever do. Don't start with an assumption that you should have a new ...


2

I don't have a ton of experience with reimplementing/rewriting an existing application from scratch, but the experience that I do have tells me that you probably don't know 80% of the requirements and use cases. Maybe you know 80% of what the existing system does, but there are still plenty of unknowns. Maybe the existing application has defects or ...


2

TL;DR Keep in mind that no framework or process can guarantee success. However, an agile framework will allow you to adapt more rapidly, and to "fail fast" if the project is not going to succeed as initially conceived. It will also provide more flexibility in determining how to implement the desired system behavior on a new stack, which is ...


2

You are building an entirely new application. The fact that you have access to an existing application which serves the same purposes using different technology will benefit you only to the extent that it illustrates the problem that is being addressed. "Desktop" applications use an entirely different architectural approach than "web" ...


1

Rewriting and re-designing a desktop application into a new Web Based application with new technology ==> That probably means not only coding, but also setting up your infrastructure, development stack, user roles, etc. Learn how to work agile. You can partially do that as you go, but you have to have your entire company aligned on the method from the ...


1

I decided to approach this, not from the perspective of the previous question that sparked this one, but from a more creative, brainstorming approach, with sympathy for the perspective of the person whose job is Resource Manager today, facing an organizational move to Agile, and wondering "what's my job supposed to be then?" I'm also explicitly not ...


1

Two of the key components in Scrum are the Product Increment and the Definition of Done. Every Sprint, the Scrum Team should deliver an Increment that is Done - i.e. it is a potentially shippable product that provides some kind of value to the customer. This implies that work doesn't get marked as done until it is Done-done, because a feature that is ...


1

TL;DR It's not a bug, it's a misfeature. The Product Owner needs to decide how much of a priority it is to address it, and then the entire Scrum Team needs to either build a Sprint around it or squeeze it into the margins as a non-essential work item as capacity allows. TAANSTAFL. You can't have it both ways, and you can't treat new work (which this is) as &...


1

Since a there was no common understanding, the developer will prefer the change as new user story as creating a bug will indicate a failure on his part. (all said and done someone is still watching the quality of deliveries and keeping count of defects/bugs). Focus should more importantly be on preventing this sort of thing from happening again as the code ...


1

It feels like there's a (potentially well intended) motivation to set how development and architecture should work based on agility principles. As well meant as it could be, the way the question is framed it implies this may not be working. I'll approach the technical aspects (merge, commit, pull request, repo) from engineering perspective. The "agility&...


1

Just to add one component to the mix: Try something, then fix it when it doesn't work. This depends pretty heavily on Sarov's answer (if the team doesn't talk, they can't fix stuff), but this is another important component of making Scrum work. For any Scrum team, its first few Sprints are likely to go askew in some way - too much work, not enough work, too ...


Only top voted, non community-wiki answers of a minimum length are eligible