Skip to main content

"IN TEST" state

Last post 02:33 pm October 20, 2017 by Curtis Slough
11 replies
10:33 am October 18, 2017

Hello,

I'm a scrum master and the testers in the team pointed out to the last retrospective that it would be of great help if they would have a "In Test" state besides the 3 basic ones we have now: TO do, In progress and Done. I agreed to add this new extra state as I saw myself that adding a task "In test" generated problems especially for stories going back and forth between devs and testers. BUT our PM manager is strongly against it. He is a "Agile champion" and he claims this is bad practice and more Kanban like. I don't really understand why adding a new state is bad practice! Is he right?  What arguments can I bring to him in order to convince him to let us add this new extra state? 

Thanks!

Cristina


04:02 pm October 18, 2017

Technically, in progress encompasses "in test" so what is the benefit to having a subcategory of "in progress"? 


05:16 pm October 18, 2017

Does it add more transparancy for the team to monitor their progress?

I wouldnt't mind visualizing the back-and-forth switching, as this implicates improvements can be made.


05:57 pm October 18, 2017

If the Development Team feels like this is the best way to organize their work to meet the Sprint Goal, then should someone not on the Development Team be telling them that they can't add this column to their board?  Why does the Agile Champion feel he can tell the Development Team what to do, even if he doesn't agree that it is a good practice?

After inspecting and learning if this works or will not work well the new column, is there yet another opportunity to teach the team that every member of the Development Team owns quality, and to examine why hand offs from one sub team to another (note the Scrum Guide mentions specifically that sub teams should not exist) may not be optimal?


07:13 pm October 18, 2017

A Scrum Sprint can be implemented as a Kanban, which is to say a closed economy of work. Therefore either approach is viable and it's up to the Development Team what they want to do.

Note that if there is a station (column) for "In Test", and a defect is found and escalated, team members ought to swarm on the item until the defect is remedied. There is no advantage in moving work backwards when you have a collaborative team.

On the other hand if tasks are raised for testing an item, and a defect is found, then a new task for remedying that defect may be planned for the item plus a new test to verify the work.


07:22 pm October 18, 2017

... our PM manager is strongly against it. He is a "Agile champion" and he claims this is bad practice and more Kanban like.

Unsure what your PM Manager's position is on the extra column.   Kanban is not anti-Agile.   Kanban and Agile are not mutually-exclusive; in fact, there are many organizations that practice both quite well.  

The PM Manager's reaction to the suggestion actually resembles command-and-control behavior, which we all know is definitely not Agile.   As a previous post stated, I would defer to the team to identify and practice what works best for them.   As a Scrum Master, you can identify potentially good practices, and potentially poor practices, and you can question such practices with the team to lead them to a better understanding of what is a good process.

 

 


08:50 pm October 18, 2017

A column called just "Test" is quite unspecific. When using techniques from TDD you can't separate test und coding. 

A column like "User Acceptance Test" or "Performance Test" may make sense. Try to explain which activities should be done in the "Test" column. What kind of tests need to be done?


02:31 am October 19, 2017

At the end of the day its team's decision to add this and if this helps bring in better coordination and visibility then so be it. This can always be brainstormed in retrospect if this would need a better name in terms of Scrum Guide which doesn't identify any sub teams.

Your PM is an Agile champ and doesn't respect Team's decision ?? What is his rôle in this Scrum team ? Because Scrum doesn't say anything about champs...


09:45 am October 19, 2017

When using techniques from TDD you can't separate test und coding. 

True, but then again, we don't know if that particular team uses TDD ;-)

I feel there are two issues here:

a) The question of whether or not to add an "In Test" column. Neither the Scrum Guide, nor the agile manifesto have anything to say about Task Boards. The reason most Scrum Teams use a Scrum Board is because it's an excellent radiator of information. It's probably one of the best techniques to make the progress of work in a sprint transparent. So that's the criteria that should be used to make the decision: Will the additional column make the progress of work during the Sprint more transparent? If so, add it. If not, what's the point? What are your testers trying to accomplish?

b) The somewhat obscure reaction of the PM merits a discussion of itself. Why does he feel it's anti-agile? If he is indeed an agile champion, maybe he thinks it's symptomatic of an anti-pattern? I would definitely recommend trying to find out why he feels it's anti-agile. I would also recommend to respectfully tell him that it is not his place to decide whether or not an additional column is added to the Scrum Board. The Scrum Board is a tool for use by the Scrum Team (mostly the development team). He has absolutely no stake in it. Or he should have no stake in it when Scrum is implemented correctly. You have a lingering impediment here if the PM feels he can tell the team how to organise. And if you do not address it, it will come back to bite you in the posterior.


02:52 pm October 19, 2017

Kanban is not anti-Agile.   Kanban and Agile are not mutually-exclusive; in fact, there are many organizations that practice both quite well.  

This is a very important call out and should be brought up to the PM Manager.

What arguments can I bring to him in order to convince him to let us add this new extra state? 

The first key point of the Agile Manifesto is "Individuals and interactions over processes and tools". In my opinion, by him being against a request of the team to add a tool in the form of an "In Test" status; he is violating the very foundation of Agile. He is focusing on the tools and processes instead of the people, that is contradictory to Agile. He could be much closer to being an Agile Antihero than an Agile Champion, at least on this one issue. Here is a little excerpt from a good Agile blog that I've found recently.

  • Agile Antiheroes can also be born from the Agile Champions in very similar ways than Agile Prophets are born. At the beginning they walk the path of the Champion, but after reaching certain status and power in their environment they give up from personal improvement and fix into certain set of ways to work that suit them well, ignoring other approaches. When they’ve fixed their approach, they start pushing it into organization as only way to be agile and use their own status to twist it so that it will lead for them to be seen in better light and gain even more power. They are not really interested in turning things for the good organization, but instead focus solely on covering their own weakness.

Blog: https://agilebackblog.wordpress.com/tag/agile-champion/

 

 


07:14 am October 20, 2017

I feel we're risking misjudging the PM here, there is the possibility that he simply miscomunicated what he wanted to say. :-)


02:33 pm October 20, 2017

I feel we're risking misjudging the PM here, there is the possibility that he simply miscomunicated what he wanted to say. :-)

Well I guess there is that possibility Julian, HaHa. That's what I hope is the case and really hope he isn't the Anithero of Agile like mentioned above. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.