Sprint & Acceptance test phase - in Scrum and XP from the trenches [closed]

Closed. This question d开发者_如何学编程oes not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 5 years ago.

Improve this question

I'm just in the middle of that book Scrum and XP from the Trenches, reading through the chapter How we do testing, in particular about Acceptance Testing Phase (I'll refer to it as ATP). Author suggests that one approach:

Approach 2: “OK to start building new stuff, but prioritize getting the old stuff into production”

but (in my opinion , or I don't get something) that approach doesn't refer to ATP at all. There's one sprint, then another, but where is ATP. Or perhaps in authors mind that first sprint contains ATP in it. If so, then how it refers to statement form subchapter Should acceptance testing be part of the sprint? several pages before:

We waver a lot here. Some of our teams include acceptance testing in the sprint. Most of our teams however don’t, for two reasons: A sprint is time-boxed. Acceptance testing (using my definition which includes debugging and re-releasing) is very difficult to time-box. What if time runs out and you still have a critical bug? Are you going to release to production with a critical bug? Are you going to wait until next sprint? In most cases both solutions are unacceptable. So we leave manual acceptance testing outside. If you have multiple Scrum teams working on the same product, the manual acceptance testing must be done on the combined result of both team’s work. If both teams did manual acceptance within the sprint, you would still need a team to test the final release, which is the integrated build of both team’s work.

So guys, (here is the question): how do you comprehend that chapter?

Apart from that here are my thoughts: author mentiones that ATP shouldn't be a part of the Sprint due to critical bug issue? Well, can't we have such an issue without ATP in sprint? Yes we can. And either way (we have ATP in Sptint or not) we are in trouble. Bottom line : if Sprint timebox in long enough (perhaps that was author's idea in Approach 2) it can handle ATP as well. It will eliminate a great deal of errors from arriving after release.

Thanks, Pawel

P.S. Do you know any pages where there's a change to have a active chat with book's author?

P.S. 2 I was just enlightened when reading through my question before posting it: perhaps by saying:

Approach 2: “OK to start building new stuff, but prioritize getting the old stuff into production”

author ment: Sprint 1 is finished, and codebase (version 1.0.0) enters ATP. At the same time we're starting Sprint 2 for release 1.1.0 and simultaneously fix bugs spoted in 1.0.0 version. When codebase prepared during Sprint 1 is spotless it goes live. So here, we have some king of overlaping. But, if that was author's intention (I'm sure it wasn't though) then it breaks fundamental principles:

1. After sprint new software is available (it isn't cos we wait for ATP to end)
2. If we consider a sprint as sprint+ATP :), then sprint is not time boxed.

All in all that book is great reading, but that chapter if a bit fuzzy (nice cool word I picked up during that reading too) to me.

---

Acceptance Test has little or nothing to do with building software.

You build as quickly and as well as you can.

User's accept some features (or reject some features).

You don't find "critical bugs" via acceptance test. The software already works. The users just don't like the way it works. It's not a bug. It's a miscommunication which will be fixed in the next sprint.

You can (with some tweaks) deploy the Accepted software, which is a subset of the tested software. People do this all the time.

We often conceal features, pages, buttons, screens, whatever, because they were not accepted. They passed unit test. They work. But for some reason they weren't accepted. So they aren't deployed.

Often, the user's original definitions were faulty, and the unit tests need to be fixed so that the code can be fixed and deployed in the next release.

Acceptance of a feature has nothing to do with whether it works and which sprint it was built in. It might be nice if it was all one smooth package. But, it usually isn't one smooth package. That' why we have to be Agile.

---

IMO at the beginning of a sprint acceptance criteria should be well known and fix for each user story. To be able to mark the story as "done" in the sprint review, the acceptance tests have to be successful. Thus IMO the ATP belongs into the sprint!

I'd like to refer to "Agile estimating and Planning" by Mike Cohn. He promotes to write the acceptance criteria on the user story post-its. They are the basis for approval in the sprint review. From this statement I derive the need to have the ATP in the sprint!

Changing requirements or acceptance criteria result in new user stories. But you never change the ones in progress.

If the acceptance tests are to be automated, this work can be done during the sprint. But the underlying criteria should already be fix at the beginning of the sprint.