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 ...


19

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. ...


18

(Repaying) technical debt is imho not a feature, because the client is not qualified to make decisions about it. Most importantly the client can't decide when it's finished, and additionally the client is totally dependent on you to explain the benefits. It is your judgment that there is technical debt, and it is up to you to decide how to fix it and when ...


17

It is a feature. As a [Developer], I want to [refactor the whizbang library] in order to [simplify maintenance and speed execution] It is defined and scheduled and tracked like any other features. If implementing this feature is not sufficiently valuable (to the client or to you) for it to ever be scheduled, that's a different problem.


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.


16

IMHO a task to eliminate technical debt is definitely not a feature. It could be shoveled into the "bug" department, but it would be stretching the definition of terms, as again it does not result in behaviour changes observable by users. I would just call it a maintenance task. In any development project, there are lots of such tasks, like setting up dev/...


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 ...


13

I think the simple answer is that traditional issue tracking software helps you to manage the backlog, whereas the scrum board helps you track the current sprint and the release. Of course it's possible to use either type of tool to do both, but you end up having to make some compromises.


10

The way you describe it preparing for a release is a significant interruption of your workflow which appears to work otherwise. As we had a similar demand placed on our team we introduced the following solution. It has mainly to do with branch management in your version control system. The concept is known to me as "No Junk In The Trunk". It basically means ...


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 ...


6

I would suggest still using Kanban by slightly changing the process: Person A does design Person B does design Person B Reviews A's Design Person A Review's B's design Person A does development and Person B Does Development and Initial Testing. initial testing Person B QA's person A's work Person A QA's Person B's work. Putting all tasks ...


6

There are really two parts to this question. One part is: How do we know when the architecture gets changed. The second part is: How do we know that the architecture is still good. For this first part: How do you know when the architecture gets changed? The goal here is to take something that is being done implicitly and make it explicit Alexei's ...


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 ...


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 ...


4

Try to go Lean here. If keeping the DONE stories past the completion of a given sprint is taking up space on the wall and not adding any value, it's a waste and it's time to make a process improvement. I'd hesitate to just throw them away until you are sure you don't need them, but I'd consider archiving them, either physically or electronically. That way, ...


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 ...


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