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.
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 4 years ago.
Improve this question
I am new to Scrum and I am trying to use it for website support and maintenance.
For website support and maintenance, we often receive small tasks, for example: replace a banner on homepage, change phone number on contact page, remove image xyz on article 123, etc... I don't know how to deal with these small tasks in Scrum.
At the moment, I create a single task in backlog, and a single Sprint for each task. Then, execute each task individually. Am I right?
In Scrum we have fixed length, repeating sprints. We bring work to the sprint, rather than creating sprints from tasks.
This is useful for a number of reasons, including:
After a while we get to know the capacity of a sprint.
We know at the start of the sprint what we will be doing and there is no change to the sprint goal during the sprint. This stability helps the team get organised.
The regular cadence helps the team get into a rhythm of planning, executing and then adapting.
Scrum isn't as effective if:
You don't have a team of 3-9 people
Work items and priorities change frequently and stable sprints are not possible
From your description, I wonder if Scrum is the best agile framework for your team.
Perhaps you might consider using Kanban?
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
What are advantages and disadvantages of Scrum over Kanban methodology.
Which one is better for mobile development?
TL;DR; You don't have an Apples to Apples comparison here.
Scrum is am empirical framework optimised for delivering Software
Kanban is an empirical method of optimising any existing process
Kanban
Kanban needs way more discipline in your team and organisation to be able to get value. You start by modelling your current processed and then make small incremental changes to the process to optimise it for your needs. Most teams fail to optimise effectively and end up where they started (or close to it) forever.
Kanban is not focused on Software Delivery and is best suited to tasks that have a relatively small standard deviation in size of batches. This allows you to monitor flow and optimise for it.
Scrum
Scrum is a Framework that enshrines accountability, inspection and adaption, and transparency as its fundamental pillars. The three clear roles provide accountability so everyone knows what they have to do. Each and every one of the Events provides a Kaizan moment to allow you to change. Every one of the Artefacts creates transparency so we all know what is going on.
The most important artefact is the Increment of Working Software because that is what out goal is. You can read the Scrum Guide to find out how it all goes together.
Scrum is focused only on Software Delivery (although modified versions like EduScrum exist) and is best suited for tasks that have a large standard deviation in batch sizes.
Conclusion
There is no 'better' option, its what works for you. I see more teams succeed quicker using Scrum than Kanban.
If you bought the board game monopoly would you expect it to come with a rule book or a strategy guide? Right, a rule book. Will the rules help you win? No, you will need to come up with, and experiment with, strategies that work for you.
The Scrum Guide is the rule book for Scrum
In Kanban you come up with your own rule book as you go along
All the practices common to either technique are complimentary.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When using an agile methodology on a team programming project, what should be done when several people needs to work in something that is to be used by everyone. For example, There is a User entity, and two people have to do requirements that need to use that entity. So, first an skeleton is created and then the activities are assigned? or what is the procedure in these cases.
And second, Is it possible to find information that addresses this kind of issues that can occur when applying such methodologies?
Thanks
The best thing about Scrum, is that it is an amazing tool for identifying bad practices. This is one of the cases. An agile team should be working with as many hands as possible, on the same requirement (requirement, feature, user story - same thing). The division of work between members should be based on the tasks needed to complete the requirement, no the requirements themselves.
Each task would be defined based on the modifications that need to be made to a certain component. Doing that will not only make the problem go away (nobody's working on the same code), but will unite the team members' efforts, and make them function as a real team, rather than a disparate group of individuals that happen to share a room and a manager.
As for official information on the subject, I can suggest reading any book about Scrum, but you might want to focus on the following sites:
Introduction to Scrum
Mike Cohn's Blog
Scrum.org
A few great books:
Succeeding with Scrum - Mike Cohn
Free ebook - Scrum & XP from the Trenches - Henrik Kniberg
And finally, if you pardon the shameless plug, you can check out my blog - I have a few posts on this subject (such as this one) and others from my experience about implementing agile methods in software teams.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
My team does some development, but is mainly involved in supprting an existing suite of applications. We now have an imbedded tester (and another on the way). So how can I apply agile practises in what is a purely reactive situation?
You could try to use Kanban. It is more suited for such dynamic situations than Scrum. The ultimate solution would be to use Kanban for support activities and Scrum for development, but in case you spend much less than 50% of your time for development this may be not worthed (overengineering).
Even though it is purely reactive, you surely have larger requests that need to be prioritized? I am using Scrum in a support situation to help prioritizing the non-emergency work that often requires hours or days of effort. I think that Scrum in some ways fits in even better in a support situation than in development.
I would start with prioritizing the issues that come in (someone from the business end should be responsible for that), making things visible (e.g. getting them up on a task board), and improving your definition of done for each task (tests, code review, etc).
Now that you have a tester with the team, it would be a good time to start some TDD and definitely start automating a lot of your tests.
Once you have some of these basics in place, you can look at either Scrum or Kanban depending on your needs. If tasks always seem to come out of the blue, Kanban is probably more appropriate as another poster suggested.
In order to be successful with Kanban, you must make sure that you have a very solid definition of done to ensure that you maintain quality throughout. Without it, you won't see the full benefit.
I would also recommend scheduling regular retrospectives to see what is working for you and where you need to improve.
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
Can anyone suggest a set of "commandments" to make everyone operate efficiently during a development project? I am looking for commandments on how Dev and QA and Management should interact. If you lookup Agile or Scrum development models they can explain peoples roles and how things work but it doesn't define a set of bylaws that protect peoples roles from each other.
Micromanagement shouldn't need to occur when rules work properly. QA should have all information they need to test and managment should define what a successful test is. Etc.
If such a set of rules existed and was known to work well, a large industry of consultants would disappear overnight. By the contrapositive, there are no "rules" that meet your qualifications.
All the roles are part of the same team, so everyone share the same goal. People collaborate, meet daily, communicating directly, preferably face-to-face.
Everything is based on trust, there is no need for "protection".
The relationships should all be spelled out pretty well in Agile. Of course, with Agile the point isn't to protect you from each other, it's to eliminate differences between you.
For instance, you are supposed to get rid of the concept of code ownership, if you find broken code you fix it. If you need help, pair with the original author.
QA needs representation in the core team. They don't get left behind because they are in every scrum meeting--as, of course, is the customer.
Management's role (if there is management) in agile is to stay out of the way and provide treats :)
These kind of things weren't just made up for fun, they really are important.
How about the agile manifesto?
http://agilemanifesto.org/
And the 12 priciples, which I'm sure you'll link through to:
http://agilemanifesto.org/principles.html
Edit
Sorry, I misunderstood the question. These are still some good principles!
Just keep communicating and addressing trouble when it comes up.
It's like in marriage: you can't prepare for every contingency beforehand -- you must be willing to deal with every setback that occurs by talking it through with your partners and finding a way to cope with it.