The Stack Overflow podcast is back! Listen to an interview with our new CEO.
13

The acceptance criteria you have listed are really a mixture of stories and tasks. Given your example story: As a user I want to register and log in so that I can register on the application and start using cloud memory I would break that down in to: As a user I want to register so that I can gain access to and start using cloud memory and As a ...


11

I would say no. As you note, user stories should be vertical slices. Another way of looking at that is that they should, by themselves, provide value. You should only burn down stories once those stories can provide value. However, you may be able to split and/or rework stories. As a quick example: Recall that stories do not contain implementation ...


10

TL;DR Neither of your stated options are truly agile. You are misusing points in an attempt to represent progress or to "hold people accountable." Neither is appropriate within the Scrum framework. Points are an estimating tool. They are only meaningful in the aggregate, and are primarily needed for estimating team capacity during Sprint Planning. Using ...


9

Answers Question 1: "Is [finishing early to allow for testing] an acceptable request?" Answer 1: It is completely reasonable because in Scrum, the Development Team is self-organizing: No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality - Scrum Guide This means,...


8

The definition of done should be something that your team can do. Having external dependencies in a definition of done is a nightmare. If you want to test your story thoroughly, which is great, you need to have a resource on your team that can do that. Your team is supposed to deliver a final increment of the product. Delivering an increment that is not ...


8

The direct answer for almost all teams is that QA must be complete to call a user story done. I would take that further and say that I have never worked with a team where this was not true. The More Thorough Answer In Scrum, a product increment (the product as it stands at the end of the sprint) must be "potentially shippable". This is a confusing term, ...


7

The Product Owner has responsibility for the backlog and the development team has responsibility for delivery. However, in Scrum we work as a team and there is nothing to stop the Product Owner discussing concerns over delivery with the development team. Just as there is nothing to stop the development team discussing concerns over the backlog with the ...


6

The most important part of this is: be yourself. Your team will work best when they are being themselves too. Having said that though, the dynamic of the team is changing (naturally) because a new team member (you) is joining. So everyone (you included) will have to adjust to find the new collective norm. You may be introverted or extroverted naturally, and ...


6

The concept is valid, which is to seek a result based on a reference. But of course it needs to be broken down into measurable points. For example: the acceptance test will be like: Achieve the same exact effect as in screen x in app y in terms of: 1. Dimming effect hex value is #9999 2. Area affected by dimmed light is 70% of the screen 3. Colorful ...


6

One of the approaches I've used in the past that works pretty well, especially with multiple teams: Set up a flip chart for each team and put a dotted line about 1/3 of the way up (so the top section is 2/3 of the chart). Explain definition of done (I also provide examples like "X% test coverage with all tests passing" and "merged to trunk") and ask them to ...


6

TL;DR Yes, the official Scrum framework requires a Definition of Done. You cannot claim to be using the official Scrum framework without defining and using one. Framework Sources The Scrum Guide is the definition resource describing the formal framework. While Scrum is quite flexible, elements such as the Definition of Done are not optional. The guide's ...


5

From Scrum.Org: The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete. Until this list is satisfied, a product Increment is not done. During the Sprint Planning meeting, the Scrum Team develops or reconfirms its DoD, which enables the Development Team to know how much ...


5

The team says the story is done. Think of this on a storyboard where the team marks the story as ready to pull (done or completed) into accepted status. The Product Owner accepts the story, (by pulling it into accepted) but their acceptance only indicates the story is done in terms of business functionality. So acceptance from a product owner, is only ...


5

When looking at problematic stories, the best advice is to use INVEST principles and in particular: Stories deliver value If QA is an activity that must be performed in order to deliver at all, then you can't split it off. Did you have a "definition of done" meeting? Does "done" include QA? If your story doesn't deliver value, it's not a story. Stories ...


5

You mention Definition of Done, and in Agile, the acceptance criteria and other user story content defines if work meets the user's needs, but often allows for shoddy workmanship. We all know we can cut corners to make things work in real-world environments. It's important to understand this has little, if anything, to do with the quality of the developer ...


5

The traditional Scrum solution would be to ask the team. Since the Scrum Team is self-organizing, much of the specific methods to do things should be left up to the team, with the Scrum Master coaching the team to ensure that the values, principles, and intents of the Scrum Guide are maintained. In practice, I would favor some kind of lightweight ...


5

The direct answer to your question is that yes, on very rare occasion, there may be something about a story or the acceptance criteria that causes the Scrum team to override some aspect of the definition of done for that case. However, it is a dangerous thing to do. This is sort of like saying that there are cases where jumping out of a second-story window ...


5

TL;DR The Definition of Done (DoD) is a living document that supports collaboration. As such, it’s primarily a communications tool that provides process transparency. A good Definition of Done defines a minimum baseline for quality. It doesn’t define a maximum for quality or create an immutable rule set. Teams can and do adjust the DoD for specific work ...


4

When a task meets the acceptance criteria, that means it's done. No other options. In real life, if a developed task meets the acceptance criteria but needs some more attention or some updates that means task is not defined well. You may need to discuss this in retrospective meetings. Possible challenges are as follows: Product ownership is ambiguous....


4

For us, "it depends". We try to take into account of whether this is, for want of a better description, "scope creep" and how much extra time it adds to the task. We're using Scrum in 2 week iterations and if a request comes through that we think we can finish in this sprint without jeopardising our commitment we accept it. Sometimes we'll say "that makes ...


4

Improve Stories to Make Features Testable The stories as you've posted them violate the INVEST criteria. In particular, your stories lack testability. If you had testable stories you'd have self-evident, testable acceptance criteria for each story. Consider the following example: As a level 4 character I need to be able to do 48 hit points of damage ...


4

I wonder if the issue is not so much closing off a task as poor estimation of how much work remains. It is pretty common in my experience to have progress stall at 90-95% complete.... mainly because of poor estimation both of what work needs done and poor estimation of resource availability. A better practice for tracking progress is to define something as ...


4

How can you "[aim] to complete all the tasks ... ahead of schedule"? Don't you have tasks to test the software? Did you mean "aim to complete all of the development tasks"? If the latter, that's probably correct -- you should indeed plan to finish all development early so that there's time for testing, and fixing bugs found during testing. If you don't ...


4

The acceptance criteria are to verify the new feature is working as expected by the stakeholders. They are better called Business Facing Tests. A business-facing test is a test that's intended to be used as an aid to communicating with the non-programming members of a development team such as customers, users, business analysts and the like The ...


4

I think the place to start is with the actual scrum ceremonies: planning, standup and retro and see if you can gather the information you want instead of forcing it elsewhere. For standup: What you did yesterday and what you are doing today are straight-forward. When I was a team lead / scrum master I found out that replacing "What are my impediments?" ...


4

I agree with @CodeGnome but not just with Agile. No matter the method, the product, or even the domain, UAT needs to belong to the users, in scope, conduct, and outcome. The client side needs to define how to conduct UAT, the scenarios it will run, procedures, training people, how to document findings, any criteria needed, etc. After all, UAT is a client ...


3

My suggestions are: Apart from having meetings, ask them for input individually; being a technically-minded, nerd introvert myself, group settings generally make for discomfort, which can be amplified when they are put on the spot or asked to share their feelings in public. Gamify where possible; nerds love games and will never turn down an opportunity that ...


3

The definition of done is used to determine which stories are completed within a sprint. If a story meets all the items on the definition of done then it is completed and counts towards velocity. If you have a story that does not meet the definition of done it doesn't contribute to the teams velocity. If, for example, the team fails to get any story to the ...


3

A few thoughts on the question: In reality, I don't see the problem here. Frequent changes are absolutely normal for Agile. Even more, this is a part of Agile. You can't make part of product "at all". There is always a chance that there will be new requirements for this part. Second principle of agile is: Welcome changing requirements, even late in ...


3

You might consider separating out the implementation from the defining of business rules. So the team would write code that satisfies "As a player, I want to buy weapons from merchants, so that I can progress further". They write the code in such a way that the price of weapons is configurable and possibly even provide an interface for a non-technical ...


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