Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My current work involves working on a large number of bugs.
We normally (non TFS) would add these to an iteration backlog (grouped into Stories) after estimating and prioritising; then work through, mark actual effort.
I want to try and understand how I would work on these bugs using the TFS Agile template as intended. But am really struggling to find best practices and examples specifically for bugs for the TFS Agile template in TFS2010.
Cheers, Nick
I hear some parts in your question:
"Add these to an iteration backlog": you can use the iteration path of the work items. Best practice is to create an iteration called backlog.
"Grouped into Stories": In TFS 2010, the default traceablity is that on a User Story you define the Test Cases which validate the User Story. The Bugs are reported against the Test Cases.
"Estimating": You can use the Remaining work field for that
"Prioritsing": You can use the Stack Rank field
"Mark actual effort": Use the Completed work field
What we have been doing is:
Raising bug during testing by a tester.
During iteration planning we may decide to allocate X amount of time to fix outstanding bugs, so we creat a bug fixing story for that iteration of X story points.
Bugs are chosen that we think should be fixed within the iteration, a task is created for each bug along with a time estimate and any high level technical details. Note the task is created as a child of the story and also related to the bug.
The key is that bug work items are not developed against directly, a related task is.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm currently confused in incremental software methodology
what is the main difference between incremental development which adopt plan driven approach and the one that adopt agile approach ?
can anyone explain to me what is the difference between those two and if my choice was good for the project?
Learning is at the core of the agile approaches. It embraces the fact that it is almost impossible to have enough information to make detailed plan up front. Instead implementing, or possibly trying to implement, your first feature will trigger very valuable learnings. Both about your implementation and the usage and actual needs in the field.
I'm not sure what "documentations are really important" actually means, but dividing implementation along module boundaries will cause a number of unwanted effects:
you can only learn about the usage of the complete system after all modules are done, a.k.a. Too late. That will drive unknown remaining amount of work after you thought you were done.
how do you know that the first module is done? Presumably based on some guesswork about what it should do, which might be right but most probably is at least slightly wrong, which causes unknown late modifications
integration problems will also show up after the third module was supposed to be finished
All three drive late realizations about problems and unknown amount of work left to the end.
Agile focuses on driving out these learnings and information by forcing early feedback, such as early integration (as soon as there is a skeleton for the three modules), user feedback by forcing implementation of one user level feature at a time with demos of them as soon as hty are ready.
It is a strategy for minimizing risks in all software endeavours.
In my mind, you should have gone for an agile aproach.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
This may be a weird question and please bear with me, I am completely new into this.
I have a list of 20 requirements (use cases) which I received from my client. With him, I prioritized this list of requirements (1 highest 3 lowest). I wrote for every requirement a use case scenario (rather than user story). I also have a use case diagram and some technical designs (class diagram, database diagram).
Now, my plan is to separate this list of 20 requirements into 5 sprints. Each sprint lasts one week.
During every meeting with my client, I can show the product with 4 new use cases implemented. If one of them isn't finished, I move it to the next sprint and my client can request a change during this meeting. During this change, the specific use case diagram and classdiagram/database diagram may be changed.
Is this considered to be Agile? (Even though he gave me the full 20 requirements from the start of the project)
Agile is sort of a big tent, but I would not apply that label to the process you've described. You are describing lots of upfront design work and a full specs up front. The schedule assumes all the req take the same amount of time to implement, thought you acknowledge that it could slip.
The primary agile feature I see is the tight (weekly) feedback loop with client.
I recommend trying on http://pm.stackexchange.com.
This is not considered as Scrum:
- Schedule is prefixed (5 sprints).
- Velocity is prefixed (4 use cases/sprint).
- No scrum ceremony is followed as such.
- All requirements are given upfront.
Please refer - https://www.scrumalliance.org/why-scrum/core-scrum-values-roles
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We're trying to implement some agile/lean practices in our software development, and one thing I've read is not to maintain a long "wish list", but to keep the product backlog as short as possible with detailed notes only about the things near the top of the list. I can clearly understand the reasoning behind this.
However, often we will have a case where a customer of a tester finds an obscure problem or edge case. We usually do some investigation to find the exact source of the problem so we know how serious it might be (e.g. could it affect other cases?) and often consider how we would solve it and/or what workarounds are available. In some cases we don't go through with the actual fix because we think the cost/benefit isn't worth it at the time, but I still want to record the results of our investigations so that if the problem happens again in future, it's easy to recognize it and see what workarounds we used, and because we might decide that it's worth fixing it after all
At the moment we create a jira ticket with a special category called "wish list" for anything like this. Is there are more "agile" approach we should be using?
Be ruthless with your jira's, there is nothing to be gained by documenting every issue you find. Remember the agile manifesto - "Working software over documentation".
Fix the blockers right away, put the critical ones in the backlog and schedule in the next sprint, for anything that isn't worth fixing, do the investigation (always investigate bugs), write a few quick notes, and close it with the jira status 'wont fix'.
In Jira, or whatever tool you use, it is common Agile practice to close such a ticket with a closure reason of "rejected" or "answered". This will maintain the minimal documentation to prove that the issue was investigated but also communicate that the cost-benefit of pursuing the issue any further was not worth it. This backlogs then should be considered completed in any reporting roll-up and shouldn't distract the team during future backlog grooming or planning sessions.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In my agile development course, after gathering user requirements, I'm asked to write a plan (for developing an application) that is supposed to define project activities, milestones - iterations and deliverables. The plan is actually the work breakdown.
So what should the initial plan in an agile project look like? If I'm giving a plan of everything in advance (as the homework asks), isn't that the waterfall model. If each iteration in agile deals with the whole cycle of plan-do-check-act, then why do we need an initial plan?
You need an initial plan because somehow you have to decide how many people are going to work on the project and develop a budget. You can never know what your scope, time, and budget are all going to be, but generally one of these is going to be fixed. Figure out which is the most important and build a plan around that. Without this as a starting point, nobody is going to fund the project.
Build a project backlog with all of the known goals. Then pull out the biggest of the goals as key milestones. Generally, a client needs to see progress towards their desired feature set. A smart client will be prepared to adjust these as the project goes, but you can absolutely lay out a series of goals to give you targets for creating working software with each sprint.
You should read Planning Extreme Programming by Kent Beck. If you ignore the extreme part of the title you can easly adapt this to your agile methods.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
When a large system developed by Agile process requires a sudden large-scale change that affects most everything, what is the best way to go about it using Agile? Does the iterative part change at this point?
For example, what if a decision is made to make a centralized system a distributed one? Or choose another large pervasive example.
Arguably large changes should have been planned for, but it's never a perfect world which is one of the reasons Agile exists, so assume that suddenly a major change is introduced that shakes the foundation.
Edit to summarize solutions:
It's incremental all the way no matter how large or small the change may be.
"Does the iterative part change at this point?"
Never.
No matter how "pervasive" the change appears to be, you still have to work incrementally, in iterations you can manage.
You still have to prioritize the changes and make them in a way that will continue to pass unit tests and can be released when needed.
You may, for example, find that fixing 80% of the system is sufficient, and you may release. Or may be required to fix 100% of the system before releasing.
You still work incrementally. In sprints. Irrespective of when you release.
Agile has no magic answers.
There's a number of approaches :-
Plot a path of reasonably incremental changes to change the system from one archtecture to another. If you have reasonably well factored code, you should be ditching the code that is made redundant by the change and keeping stuff thats independent of the change.
Another approach if things are really different, start a parallel development of components for the new system.
Or, start new and steal as much as you can from the old project.
Depends how BIG the change really is.