New answers tagged

0

Scrum does not work well with separate projects that overlap, as you don't have a stable set of people working on a project for the complete sprint. Hence concepts like verbosity etc are likely just to depress you. But first taking the story that give the best cost/benefit to the client, and implementing it including full automated testing, to a quality ...


2

Your situation might be a better match for Kanban, since you can start with you have and iterate from there. This means you wouldn't have a big bang introduction which is disruptive to your current projects - just start by visualizing tasks on a board and adopting some of the practices such as retrospectives and daily meetings. You have to be a bit more ...


5

You ask for alternatives so I'm going to say eXtreme Programming (XP). Specifically I think that pair programming might help you here. By pairing people with different skills together, it doesn't matter on what skill: making coffee, testing, training etc. you can spread the skills around the team. But to be honest it doesn't sound like SCRUM is that far ...


2

How to make Scrum work for a team with defined roles? Just do it. According to the scrum guide everyone is a developer but back here on planet earth, different people will bring different things to the table. I nearly got lynched when I suggested that some people are really testers while others write the software. Some things you might want to address: ...


15

Actually, your current way of working isn't that far removed from Scrum as you might think. In Scrum, you also get an initial set of requirements, implement those and demonstrate the result, and based on the demonstration, new requirements can be given to you or the stakeholders can decide that the product is good enough that no further development is ...


1

Config : You can disable the feature, make it unavailable or hide it from the product owner and plan in the next sprint what will effectively be done with this (fix or complete removal). This requires a bit of planning, some config and has some impact on how you code the feature. Code Isolation : As many have stated feature branches will help, and for ...


0

In a past job we had a similar setup (DTAP) though we did not use SVN (we used Perforce) it would have been easily ported since both are or the same VCS family. We had a development branch where all development occurred. Since branching is fairly costly in P4, same holds true for SVN we did not use sprint branches, only when a feature, or user story, or ...


4

The main issue is with our backlog, we have a product owner who is also the IT manager. Virtually all of the items on the backlog have really poorly defined stories, nothing has any priority and no one else in the business seems to be having any input into the backlog. This can be summarized as "the Product Owner is not doing his job". This is a ...


0

The mistake management make time and time again is taking the sum of sprint estimates to be the delivery date. In fact, I've seen management set a delivery date in stone before the first sprint has completed. Tools that assist with planning are a means to an end - they shouldn't be a tool to beat the developers with. Estimates are indicators for time-lining ...


2

I've noticed many times a shop will react to an identified problem in their methodology by changing their methodology. This is often the most dysfunctional thing to do. "We keep missing sprint deadlines." "OK, make the sprint longer." This even seems to work. But it really only hides the problem. The methodology will not make you better. It will ...


7

I dislike Scrum. It has been described as the least agile agile methodology ever. I think its the cause of much inefficiency and a lot of friction between management and development. Understand that all published agile methodologies are starting points for your own modification. Scrap the bits that do not work for your environment, add bits that you think ...


0

The literal answer to your question is "the product owner". The product owner is responsible for delivering valid stories with acceptance criteria to the team. However, scrum is merely a framework to help teams learn to be self-directed. The rituals and practices are there to guide a team. At the end of the day, the goal is for a team to work together to ...


0

The scrum guide is pretty clear in this regard. Everyone must agree on what "done" means. Once done criteria are set, you have a body of work to start with and can start putting the work into sprints. Until someone (hint: product owner) grasps the nettle and does/facilitates this work it cannot be allocated to a sprint as it is an obvious fatlog.


3

It is the job of the product owner and scrum master between them to ensure that the user stories on the backlog are in a state where they can be estimated by the development team. If that isn't happening (and "I need the current application branded" can't be estimated), then you need to be pushing the user stories back.


3

As a fellow lone developer, it's difficult to see the need for a lot of things that are more beneficial for a team especially in areas of communication and documentation of time. How much do you want to fine-tune your estimation skills. You may find out there are areas you're not considering (e.g. deployment) or you may underestimate or overestimate some ...


0

For us, it is just a drill down category for reporting. They save having to wade thru the task description to find out what sort of activity it is. If nobody has eyes on your sprints and aren't creating any sort of reports and the like then it can be tempting to ignore this but it really isn't that much extra work. At a macro level they can be used as an ...


0

Assuming it can't wait and a rollback is not necessary, impossible or undesirable, you split off into two parallel sprints. Of course you need to split your resources to do this but hopefully it's just one dev and some QA time. One sprint takes the current production branch and develops, tests & deploys the hot-fix and only the hot-fix. Because of the ...


0

Roll back the previous deployment and queue the work in the backlog. If you get 'critical' bugs like this its points to a failure in testing, rushing in more changes only makes things worse. You push back the next release, which is in turn rushed through, which leads to more bugs, which pushes back the next release.. etc Roll back the release, take time to ...


1

Let the issue upset/break into your current sprint This is usually not a popular opinion but: fix the issue. You dropped the ball last sprint. Let it cut into your velocity for this sprint. This will create incentive to not drop the ball again and make your velocity more realistic due to including fixing of issues that do happen. However if it is possible ...


0

You are not doing Scrum. It may be agile but the way you let your stakeholders disrupt the sprint defeats the purpose of Scrum entirely. Scrum would be agreeing on some functionality to be built, then build it the way the team deems sufficient in the coarse of a sprint and then, at review/demo day at the end of the sprint, present the results to ...


1

When an issue is found, you first do a triage of the issue to determine if it is a really critical "fix now" problem or if it can wait and be planned along with the other work. If the issue really has to be fixed immediately, then you should pull it into the current sprint as unplanned work and track how much time the team spent on it. At the end of the ...


2

Whether you start fixing it immediately or roll the update back shouldn't be based on the status of any sprint. This item should go on the backlog and you may need to do some sort of mini sprint for a few days or just extend the previous sprint. Fix the problem and don't worry about Scrum too much. The whole point is to be agile and not to arbitrarily stick ...


4

One of the core tenets of Agile is that it is more important to figure out what works for the team than to blindly follow the rules. Yes, the "rule" is that you never take in work mid-sprint. The reality is sometimes messier. If a critical defect comes in, and maybe a flaw is costing you money, or opening your company up to liability, or leaving an ...


3

See this link https://www.youtube.com/watch?v=ZXmC_fku15Y for why scrum is a useful metaphor for a closely knit team in the Agile methodology. The use of scrum in this context was first brought to the attention of an English reading audience by the two Japanese authors (Hirotaka Takeuchi and Ikujiro Nonaka) in "The new product development game", Harvard ...



Top 50 recent answers are included