Hot answers tagged

34

There are (at least) three different ways a team could work. Choose the one that works for your team. 1. Detail vs. High-Level Overview Use the issue tracker to keep track of individual tasks. Use the card board to maintain a big picture of the major features, as a summary of the tasks in the issue tracker. 2. Bugs vs. Features Use the issue tracker to ...


22

There's a lot of different styles, methods and mindsets related to the whole field development, and everything has it's own, shiny name. Agile is just a mindset that moves away from the usual, static programming models (like waterfalls) - it's primary goal is to achieve more flexible development and (at the very end) better software and happy customers. ...


16

In my view XP is a programming practices, Scrum and kanban are project management practices. They have a relation but do not replace each other. In our kanban project we use pair programming (mostly for complex sections and debugging), TDD, CI. So it is still used but management is pushing the project management side harder.


15

You're right that Kanban doesn't have the concept of Sprints or Sprint Planning like Scrum does. That's because it's a leaner methodology. More things are done just-in-time. It's up to you to decide how to schedule planning activities, but I would recommend doing them as close to the start of work as possible. This is most effective when there are ...


8

Ah, you're shooting a moving target and expecting people to pretend it was standing! You should make up your mind on a target. If remaining ticket count is a metric, it's unfair to add tickets, especially externally, in a forced way. In SCRUM when a sprint is planned the team commits to its content at the start, unanimously. From that point the content ...


8

Place the bug items on your Kanban board like everything else (in prioritized order of course) and then let the team decide who should implement the next item in the queue. I believe the team knows best how to handle this, rather than having someone else distribute the items among specific team members. At least that will give them an opportunity to self-...


8

But my team is working using agile methods (a combination of scrum and kanban), so what we need is user stories. This is a misconception. Neither Scrum nor Kanban require that requirements be specified in user stories. Both are silent on the issue. The Scrum Guide refers to "Product Backlog Item". These items have only a few attributes - description, order,...


7

Assuming Kanban (as I think the answer is less relevant for a Scrum process), the lanes that you should use depend on organizational concerns, and perhaps on your definition of done. You'll probably start to see an obvious need for things as you start working through organizational or business concerns beyond just development concerns. In my current ...


7

Where did you get this definition from? I'm reading this definition from the chapter "Estimate your work", which doesn't include done work.


7

At the end of an iteration, it's not required to release a software product. Scrum calls this an Increment, and other methodologies may have different names. The purpose is the same - at the end of your iteration, have something that is in a state that could be delivered to a customer or user. I can't speak to the specifics of Service Now (and this ...


7

One solution is to adopt the "LTS" (Long Term Support) model used by Linux and browser vendors. At the end of a sprint, if you have a version fit for release, you create a release. Give it a version number, label it in git (or whatever version control you are using, but I'm assuming git here), update the docs etc. You then effectively deploy that release ...


7

No. Scrum is designed to fight exactly the issues you are experiencing. You could switch to a reactive approach fixing bugs as they are reported as quickly as possible, but this comes at the cost of predictable completion dates and often the stability of your software. I would say you should push back, ensure all requests go in the backlog and are ...


7

The ticket should be in the column it belongs in, which sounds pretty stupid to say and is exactly why I'm mentioning it. The ticket was being developed, then handed off to QA who found some defects. The ticket now goes back to an engineer to be fixed. Thus, the ticket should go back into development. Each column has a group of people or teams that are ...


7

I'm curious why you bother to do estimations at all if you don't have a way to eventually boil it down to approximate actual time. The only reason I can think of is to be able to say "that's too big" and break it down further. Anyway, the most common way to convert your estimates is to measure your actual performance over the last several months. If you ...


6

I'd say make items the size they can be easily made to. "Start with what you do now" is one principle of Kanban. So split the work like you do now. "Agree to pursue incremental, evolutionary change" is another principle. Start implementing small changes if you see problems in the way you split work. Don't get hung up on analysing and designing your "Kanban ...


6

The ultimate goal with any estimation approach is to be able to translate the estimates into 'real' terms. Otherwise, what would be the point? What use do t-shirt size estimates have if you can't translate them into real timelines? The reason that relative estimation techniques are used is that people are absolutely terrible at estimating in absolute ...


5

Full disclosure: I'm a little biased because I'm the GreenHopper product manager at Atlassian, but I've also been involved with Agile development outside Atlassian for a long time Having just an Agile planning tool or just an issue tracker is definitely viable. The problem is that it's sub optimal. In my experience it's sub optimal because: Product ...


5

Move it back. Agile development environments need to function based on their "definition of done", and until the task is "done", it doesn't flow off the right edge of the board. In a good agile environment, "done" includes tested-for-unexpected-behavior and verified-against-requirements. Even better than the motherhood-and-apple-pie aspect of not ...


5

Frankly, I think you should look at them all. Scrum because it heavily emphasizes iterative and incremental development. XP because it gives a lot of advice on the technical side of development. Kanban because it emphasizes WIP limits and flow. That's how I've come to know them anyway; I've noticed they've all influenced each other heavily over the years. ...


5

"[...] reported many critical bugs that needed immediate attention" sounds nasty. If your team can solve 5 bugs per day and dozens of users reported dozens of bugs which all need immediate attention, there is no way you can do what they want. They simply have to wait, and the higher is their leverage to hurry things, the worse it will be, because rushing ...


5

You are slightly misrepresenting/misunderstanding what the Sprint Planning meeting does in Scrum which I think is the cause of your confusion. A Sprint Planning meeting is usually the wrong place to work out the details of stories. Other than some final tweaks and a quick run-through to make sure there are no outstanding concerns that would significantly ...


5

Rather than feature branches, I'd recommend using feature flags. Essentially, these are just conditionals in your code that determine whether a particular portion of the code gets run or not. You control the status of the feature through configuration, which can be as simplistic as an app setting in your Web.config or as complex as a third-party service like ...


5

The two approaches are very compatible. In fact, it is completely possible to use both. That said, as you adopt Scrum, there will probably be two significant differences. 1) Scrum is very team focused. That is not to say that you don't have experts on a Scrum Team, but the whole team is responsible to work together and that means a lot less of "my work" and ...


4

Wow! That took some time to fully digest and understand. Congratulations on deciding to adopt Kanban for your Agile initiative. Really nice analysis and modeling so far. Thanks for sharing it here and allowing us to help and contribute to that initiative! I have some thoughts and suggestions – hope these help! A. First, just to get an overall “system ...


4

Don't have a separate column. I know it's an example used everywhere but it's more geared at highlighting waste between steps, the TDD cycle is pretty tight. I'd recoummend Development column with sub column Dev Active and Dev Done. Then next would be Demo Active and Demo Done, Prod Deploy Active Prod Deploy Done. What this let's you see is how much time is ...


4

I am not sure you have quite precisely put your finger on exactly what the problem is, especially due to having taken on the new large customer. Are you starting to miss sprint goals/ deadlines? Are you seeing quality suffer? Are you seeing throughput/ velocity drop? Are you losing new prospective customers to competition because you are no longer working as ...


3

I agree with the other answers: Don't worry too much about the size, try it and improve - that's the Kanban way :-). To still give you some concrete values, here's what our team does: Minimum size is about 30 minutes - smaller cards cause too much overhead and clutter the board. If something needs to be done that takes <30 minutes, it (usually) gets ...


3

It's up to you, and what you feel comfortable with. I pick a size of "easily understandable and doable". Sometimes that means getting started, realizing it's more complicated and breaking it down more and/or being more clear. It's just tasks on a list. Size isn't all that important, unless your trying to measure throughput, in which case your probably ...


3

While I agree there is no formula as such - at the same time there is the real possibility of modelling your Kanban process. This will help you simulate likely outcomes for things such as Cycle Time, Wait Time, Efficiency, etc. I have implemented such a simulator which models our Kanban process. It simulates the flow of stories across the board under our ...


Only top voted, non community-wiki answers of a minimum length are eligible