In the agile scrum methodology, if we fail to identify the hidden areas in the project plan on the burndown it could pottential cause a major threat to the project. Also if a resource miss-interpretate the item on the burndown it could lead to a confusion as well. If we do not make an attempt to identify the subtasks and the overheads on the burndown it could turnout to be costly in the end. What are the potential risks involved with agile test planning and what are the possible solutions to manage those.
+1
A:
There's a trick to Agile.
The trick is this:
Keep things small and simple. Build the smallest, simplest thing that has value.
If your sprint is small and simple, there's not much to be "hidden" (whatever that means to you).
If you have daily scrum stand-up meetings, "misinterpretation" can't last more than 8 hours. The next day, you correct the mistake. I'm not even sure what "misinterpretation" could mean when you have daily meetings.
Each developer identifies what they'll do for the sprint. And you revisit that list of tasks every day at the daily standup meeting. You don't have complex "subtasks and the overheads" because -- well -- your sprint is small and simple. Just tasks. I'm not sure what overheads could exist, since you've got so little time to create a release.
It might help if you listed specific "hidden" tasks or "misinterpretations" or "overheads" to clarify your question,
S.Lott
2009-08-06 16:02:07
or, "Keep things small, simple and stupid. Build the smallest, simplest thing that has the least amount of intelligence that has value.
Lucas B
2009-08-06 17:09:56
@Lucas B: The "stupid" and "least amount of intelligence" don't really need to be repeated. I think "simple" says it all. Further, some AI algorithms are pretty simple, so some "intelligence" may be consistent with simple. Usually, however, a focus on simple means removing tricky, complex, poorly-understood and over-automated features.
S.Lott
2009-08-06 17:37:37
Sometimes there are dependencies on other resources and other teams and those are not managed well on the burndown plan. Things which are environment base, business input for data etc consumes time.
Chanakya
2009-08-06 18:43:00
@Chanakya: Please update the question with your examples. Please try to be as concrete as possible: "other teams" could mean anything; "business input for data", similarly, could mean anything. The point of Agile methods is to be specific and plan a specific sprint for a specific need. Please try to be concrete. And update your question.
S.Lott
2009-08-06 19:53:36
A:
Are there separate testers in the project or are only the developers testing their own code? This comes to mind as an initial question to consider as there is more than one way to go about setting this up. When would there be sufficient product that testing is worthwhile is another point to ponder. If you take a month to get an initial prototype that can be tested, do you want to have QA initially coming up with hypothetical plans all the time or just come in when there is something to test and use right off the bat.
Specification ambiguity can be a potential issue where a tester and developer interpret something differently and someone else has to decide who is correct. While this may seem childish in terms of, "I'm right, this other person is wrong," mentality, it can be an issue at times. This could also lead to a lot of work done initially in breaking down every task that may take more time to document than do which leads to questionable value to my mind.
How much access to the code would the testers have? For example, do they get to see all the source code and write tests for every little thing, or do they merely test the finished product using black-box testing?
I recognize this has more questions than solutions, but there are a lot of variables to consider here that may guide an answer.
JB King
2009-08-06 16:02:54
A:
It sounds like the development plan is the potential risk to the testing plan in this case. If you don't understand what you are building, you will not be able to limit the scope of your iteration properly, and there will be too much to test. You should concentrate on changing what needs to be changed, and understanding what needs to be changed.
Basically, not understanding the scope of the iteration at the start is a huge risk to the iteration and it's proper testing.
If you come out of your planning meeting without a good idea of how the iteration's development should be done, you can't have a test plan that is all that likely to be correct.
stevedbrown
2009-08-06 16:12:57
This is an interesting observation. I am looking for some other things on the similar line. Sometimes there are dependencies which can cause pottential delays and those delays are not listed in the burndown plan.
Chanakya
2009-08-06 18:26:48
Iterations should be short - when possible, build against the uncertain dependencies in one iteration and finalize and release in following iterations. This way if the dependencies don't come through, you are okay in terms of planning.
stevedbrown
2009-08-06 18:58:23
A:
There is no efficient way to perform an unnecessary task.
"Misinterpretations" that last for more than a day or two usually indicate tasks that aren't very well thought out (unless this is a ongoing issue with the developer not understanding what is being asked of them)
It sounds like the project plan is being used as a substitute for a business plan. These are not the same thing. One can not substitute for the other. I've seen situations where a team is able to deliver good code that meets the needs of the users, week after week and have it been totally useless for the organization.
I would get a Biz Analyst who can speak the customer's language involved. Go through the backlog and ask how those task somehow translate to an organizational benefit. I would also sit down with the developers and make it clear that "its cool and I want to" is not a business case.
sal
2009-08-10 14:56:52