Hot answers tagged

93

I recently experienced exactly the same situation you are describing. While I'm not the Scrum Master for my team, I was the only person on the team who had used any Scrum methods previously. To solve the issue of things coming up and derailing the Sprint plan, we adopted a method we call 'The Batman' which, after some tweaking, has really worked for us. ...


53

If at all possible, they don't. They ask developers to estimate it. Estimates should always be made by the people who will perform the work being estimated. If this is not done, then you run the following two risks: The estimate is inaccurate, as the person who estimated it did not have the knowledge of what work needed to be done The people who do the ...


49

Pretend the Waterfall team is an outside contractor Since you're interfacing with the Waterfall team's code solely via an API, just pretend you're hiring an outside contractor to create that code for you. The Scrum rules for how you write your code don't apply to them. You submit your requirements to them, they write up a formal Statement of Work for ...


38

Each organization and author has a different definition for these terms. In this article, Mike Cohn provides his definition of User Stories, Epics and Themes: A user story is simply something a user wants. User stories are more than just text written on an index card but for our purposes here, just think of user story as a bit of text saying ...


33

With that much variation in the estimate, it seems like the work as it's currently defined is not ready for estimation yet. Based on that wide spread in estimates, I would say that the team doesn't have a clear understanding of what is required to complete the work. Unless the work was critical and must be started and get to done as quickly as possible, I ...


32

Which one is better? The one that works better for the team. That is the entire point of Scrum. Enable your teams to organize around practices and tools that work for them, and stay out of the way. It really doesn't matter what your Agile coaches like and don't like. Their opinion can be used as a basis in your team, but the bottom line is to use what works....


27

TL; DR Agile release planning is based on fixed-length, normed-capacity cycles that operate on dynamically-planned and dynamically-scoped features. In Scrum, fixed-date release planning must be handled by controlling scope to meet the deadlines, as you cannot have both fixed-date and fixed-scope deadlines simultaneously. This is rarely a practical problem, ...


26

It's impossible to answer your question because "Scrum Master" and "Product Owner" are roles, not job titles. Their job positions may be different and depend on the company. For example, a Product Owner could be: A business analyst at your company. A person from the customer side (i.e. outside your company). Or even the СЕО of your company (it's not rare ...


25

There are different ways of tackling this: Zero-bug policy If you plan your sprint just with new features, but keep a zero-bug policy then your velocity will drop. Eventually you will know how much stories the team can get done while fixing any open and new bugs first. Understand Yesterdays Weather and plan accordingly. Placeholder PBI Each sprint add a ...


25

I don't think there is a simple answer to this question. Instead, I think there are a number of different scenarios: A team is very experienced in Scrum and rotates the Scrum Master role. They have no need for a full-time Scrum Master. A team is very experienced in Scrum, but they still face impediments and they prefer not to be distracted, so they ...


25

It seems to me that you are trying to fill each sprint to capacity, and keep everyone fully utilized. Planning for 100% resource utilization is a bad idea. You will only end up with busy people and delivery will suffer. The point with Agile and Scrum is to deliver value. One QA tester to five developers can quickly turn into a bottleneck while work moves ...


24

The situation you describe is Scrum Zombie, not Scrum. My answer will try to organize a few of the aspects you mentioned. Software developers are not resources business needs the resource and cannot afford to lose time One of the perpetual problem of our industry is to simply assume that people are interchangeable cogs in the machine. In the situation you ...


23

TL; DR Story points represent consensus within the team. The goal of estimating story points is not to provide the largest or smallest estimate, but to accurately reflect the effort required by the entire team to meet the "definition of done." Lewis Carroll Does Scrum Consider a story like: As a practitioner of Extreme Dentistry, I want to know how ...


23

The first thing you should do is encourage the team to bring concrete arguments. "Things are more complicated than they seem" or "I dont think those complications are valid" are very vague arguments. "I disagree, because the database-adapter has 3.000 lines of code, so changes in this class are very hard" or "Finding all methods doing X takes a long time, ...


23

I don't see any problems with raising concerns that you are aware of yet don't directly impact you. There may be ramifications to your relationship with coworkers if they see that as breaking some level of trust with you, but there's nothing from the process side that would prevent someone from raising a concern or issue on behalf of someone else. The ...


22

You don't make any mention of a Scrum Master in your Question, so I'm going to assume that either s/he doesn't exist or isn't helpful. If not, make sure you involve the Scrum Master! It's his/her job to address process issues. That being said, Scrum provides a tool to address things like this - the Retrospective. Here's what I would do, in your shoes. For ...


21

Working sprints that end/start mid week is usually more effective/efficient than ending on a friday and starting on a monday for several reasons: It makes the last minute rush to complete work more painful and less desirable for the development team (eliminates the excuse of, "hey we can finish it over the weekend). Reduces the risk of paying weekend ...


21

when pushed to do 60, they will deliver 60. This is a pretty meaningless measure in these circumstances. A team could drop quality to deliver more points or simply game the estimation of stories. Story points and velocity were designed to help teams estimate their capacity in a sprint. They are not intended to be measures of performance. If you want to ...


21

If the team is truly self-organizing, then the members would recognize that they have an issue that needs outside assistance and would, among themselves, find a way to resolve it. One option would be seeking someone else, either inside or outside the organization, who is a subject matter expert who can provide an expert decision. Another option would be to ...


20

It is possible that a developer also acts as a product owner but I don't think that it is recommended. Here are my 2 main reasons: It may create conflict of interest It will drag down your output as a developer PO has to prioritize the backlog (the what part) where as the team decides amount of work that can be delivered in each sprint (the how-much part). ...


20

TL;DR I was wondering if it's a good idea to name Sprints with user-friendly names instead of using numerals like Sprint 1, Sprint 2, etc. No, it's not a good idea. A sprint is a container where Product Backlog items are temporarily stored for a brief duration. A sprint may produce some project artifacts, but the sprint itself has value only as a time-...


20

You might tackle it by highlighting increases in development costs caused by technical debt. That is a problem we are facing right now, too. Business is requesting more and more features they need when my team really wants to remove technical debt. We underlined that with less technical debt new features can be shipped way faster- and faster means cheaper. ...


20

When estimating user stories, everyone should be estimating the complete effort it will take the team to get the story to Done. So, the back-end dev should not just estimate the effort it will take him to do his part, but his estimate must also include the effort for the front-end, the design and all testing (and similar for the other team members). The ...


20

The phrase "backlog grooming" was officially replaced with "backlog refinement" in the Scrum Guide back in 2013. The change was largely done for: Clarity of semantics. Arguably, the word refinement expresses the idea of continuous improvement a little better than grooming. The latter denotes removing defects or straightening out. ...


20

The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn't add much value. Common times that Scrum teams estimate stories: Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. ...


19

I'm a bit unclear how you are managing the management/support requests. Actually, I'm unclear whether you are managing them at all. You need to manage these requests, to protect your developers. Software developers can only be productive if they have extensive time "in the zone". Interruptions are the number-one thing that can kill developer productivity ...


19

To tweak the Field of Dreams quote "Do it and the tools will come." Tools are not the solution, they are tools to aid the solution. You need the solution first. Start running agile with a physical task board or if you absolutely need a tool, use something free like Trello. The key is to show success using an agile framework (I'll assume Scrum) and show ...


19

Awesome for you. The retrospective can be one of the most fun and informative "ceremonies" of agile. So once you get the book, Diana is going to recommended never falling into a rut and tailoring your retros based on what is the needed to be focused on, or to take the team into a new direction. When you first get started though, simple is very good. ...


19

Coordination/Collaboration, Not Formal Task-Tracking While the Scrum Guide used to refer to the stand-up as a commitment meeting, it currently says: The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The purpose of the daily Scrum is not to hold people accountable ...


19

If you reduce a team from 7 to 4, especially if the reason is something outside the team, the best course of action is probably to treat this as a completely new team. People will need to change into new roles, find a new way of working together, cover fresh weaknesses caused by those leaving, find out who is in charge of what, and all the other problems ...


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