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 7 months ago.
Improve this question
Im working on the agile management system in GitLab.
For example i have issue X assigned to milestone #1, i couldn't finish it and would like to take it to the next milestone #2. In GitLab that's not possible to assign to multiple milestones. So I tried two scenarios :
Duplicate the issue and assign it to milestone 2
create a label that indicates that it belongs to the previous sprint What would you use? (it's weak because its gonna affect milestone #1 charts, completion percentage..etc)
Any suggestions?
How would you do it?
Issues can only be assigned to one milestone at most at any given time. You mentioned a few ways to handle this, which should work as well.
The way I've seen this typically handled is that you would change the milestone if you miss the original milestone target. To keep track of the fact that the issue belonged to a previous milestone, you can add a label like missed:old-milestone.
This is how GitLab handles its own issues and milestones.
For example, this GitLab issue was originally targeted for 15.2 milestone, but wasn't completed in time so its milestone was changed to 15.3 and the missed:15.2 label was added (both actions were taken automatically by a bot when the 15.2 milestone was closed).
This is a good practice, particularly when you use release versions or fixed-date milestones, because it becomes easy to see what issues actually make it into a particular release/milestone (important for communication/clarity). You can use the missed labels to figure out what work was planned for previous milestones but was missed.
As you pointed out, this will affect how metrics associated with your milestones are displayed. You may choose to snapshot your metrics before moving issues between milestones, if you want.
The approach you choose is a personal choice and the impact depends on exactly how you are using milestones.
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
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 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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I began using a bugtracker (www.bugnotes.com) so I am new to this... And I am easily adding bugs, makes sense. However some of these bugs would be fixed if I were to implement a given feature or perform some refactoring. So how can I track todo-list type things effectively, and don't these kinds of tasks tie into bug tracking? I guess what I am asking for is tool that tracks both bugs and features since they are all code changes.
Oh and putting minor fixes as #TODO or //TODO: is great actually, I like this for minor things, just not big things like refactoring, or changing a driver or a library.
Also, I was using a text file but the problem with that is that so much of what is typed into there becomes old and therefore the whole thing is kind of useless to me.
Any bug tracking system can be used to log bugs, features or general to-dos, as each is comprised as some form of work unit. The advantage of storing these in a bug tracking system is that all outstanding tasks are visible and can be prioritised. If you rely on TODO in the code then it is difficult to see these at a glance and hard to prioritise or see where you are with them. As a result, in my experience if you rely on TODOs then the list of these only ever gets longer. If you have some code that is incomplete, I think it's better to turn the TODO into a bug entry and then replace the TODO with the bug id, so you have a link between the code and the bug. A side benefit is that when you actually do the work and commit to version control, you can also add the bug id in the checkin notes and so you've got a permanent record of when the change was made.
If you have lots of TODOs already then it may be worth looking at a Hudson continuous build system, and add the Static Analysis plugin, so that you'll get a daily graph of the number of remaining TODOs, cross referenced with the source. That will at least present everything in one place and give you a burn down graph as you fix each TODO.
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.
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
Most Scrum teams have some sort of whiteboard or other board upon which the stories/tasks for the current sprint are visualized.
I'm curious as to how people organize this board? Do you use post-it notes? Are they color-coded? How do you group tasks? How do you distinguish the state of tasks? Etc...
I've seen groups use a whiteboard, and use different colors for each group of tasks.
If you use note cards for your stories, you can put them up there as well, and divide them by release/iteration/group of tasks. This concept is explained better here.
Update: I also use spreadsheets to visualize my sprints/iterations, because my team is not all co-located. I use tables and graphs similar to what was mentioned in Jim's answer.
Not for everyone, but for those running TFS, Scrum For Team System provides excellent sprint backlog reports.
Failing that, Ive personally maintained sprint backlogs using a spreadsheet, as per this article. Sharing via something along the lines of google docs.
Somewhere on the web there is a blog post which is just a lot of scrum boards. It is really good to see how other people do it. Maybe someone can find it for us :)
I think this looks like a pretty comprehensive way of doing things!
http://www.xpday.net/Xpday2007/session/AgileInGovernment.html
Check out the Rally tool at rallydev.com.
Depending on your needs, there is a free community edition. It's very easy to track stories and tasks within a given sprint, including estimations, actuals, and states for each story and task.
I usually use an Excel sheet, on a shared network folder: one column is used to specify the "group" of the task, and one to specify the task itself. For completed tasks, we simply mark the row in green. The primary disadvantage for that is sharing - I've yet to find a decent solution that allows more than one person to edit the backlog. We have some ways to deal with it (by limiting the updates to a specific time of day, and then having the team update it together), but it is still annoying.
For sprints with a small number of tasks, we simply write the tasks on a whiteboard, and strike over the tasks as they are completed.