Is it possible to create a Definition of Ready (DOR) board and a separate Development / Sprint Board for Defintion of Done (DOD) AND be able to transition a work item from the DOR board to the DOD board i.e. One workflow visually representing the preparation of a story(DOR) and the build of a story(DOD) but on separate boards.
DOR board columns might be: Backlog, Business Review, Technical review, Product Backlog refinement (PBR), PBR Done, Prioritised, ready for Sprint
DOD board columns might be: Sprint Backlog, Development, Code Review, Testing, Testing Done, Completed
This is very doable in Jira (Atlassian) and although lots of you tube videos that describe how to setup a project, a board, work items, epics/features/stories and how to assign to a Sprint, this all speaks to the build/delivery of work. How is the preparation of a story visualised on devops boards separate from the teams sprint boards.
I have researched a lot of articles and looked at youtube videos which don't discuss this issue
Related
How can I add the same work item to two different sprints/sprint boards?
My scenario is given below.
I have a big team that is following a longer sprint length (1-month sprint cadence for example)) and a sub-team that is trying 1-week sprints. I have done the project and team configuration (using area paths and iterations pats etc.) such that the sub-team sees only their backlog view and the big team sees the whole backlog. I can drag the work items from either one of the backlog for either one of the teams to corresponding 1-month sprint board (for the big team) or 1-week sprint board (for the sub-team).
My question is as follows:
The bigger team wants to see all the stories as part of the month-long sprint. In other words when they have standups they want to see the sub-team's 1-week sprint stories also in their sprint board for the month-long sprint. I tried to add the same story into both month-long sprint for the big team and 1-week sprint for the sub-team. But Azure DevOps cannot keep the work item in both the sprints at the same time. It you add it to month-long sprint board, it is removed from the 1-week sprint board.
How I can have the work item be added to both the sprints? Any help is appreciated
You can set up sub-teams and sub-sprints using Azure DevOps logic, then the work items will be automatically synchronized on the backlogs of both teams.
As shown below:
"Team 2" is a sub-team of "Case0103 Team". And "Week 1" sprint is a sub-sprint of "Iteration 1".
Then in Sprints, "Case0103 Team" can view work items of "Iteration 1".
"Team 2" can only view work items of "Week 1".
Here are the detailed steps:
Create a sub-team. You can click Configure a hierarchy of teams for detailed steps.
Create sub sprints. You need to go to Project Settings -> Boards/Project configuration, then choose your sprint and click "New child".
Set iteration paths. Go to Project Settings -> Boards/Team configuration -> Iterations. Select different teams by navigation bar at the top and select or remove sprints. Team members can only see sprints shown here.
We plan to use Kanban in our DevOps project. It however looks like I still need to create Iterations (e.g. 14 days) and map the Kanban widget to show the WIP over the 14 day cycle.
So, in essence I still need to create Iterations. And a follow up understanding accordingly is that I will need to do sprint planning for the iterations. Is that the correct understanding or am I missing something?
Thanks
Two things here:
First, Kanban is mainly used to visualize the state or flow of your work. It is interactive in that you can change the state of the workitems as it progresses from one state to another. Kanban boards are not really dependent on sprint as such, but provide a cumulative flow chart for monitoring progress. It is the Taskboard that is tied to tracking the sprint tasks.
Second, the WIP limits are used to limit the number of workitems in progress, and can help identify process bottlenecks and improve the Team's efficiency. These numbers are set per stage and act as the soft constraint that can be revisited later.
And yes, you have to create the iterations and iteration dates, although they can be as per your pace, and map your Team's work flow to Kanban columns!
Additional references:
Kanban Basics
Kanban quickstart
What is Kanban?
If you want to re-evaluate your process model, give this doc a prior reading.
Hope this clarifies!
Well, Kanban cares about Flow. That requires some understanding of Queuing Theory. One aspect is for example Little´s Law. Which requires Delivery Rate. So I find it valid to ask for that metric (without iterations!) when Kanban is supposed to be supported.
Second, Kanban cares about Balance. eg between work arrival rate and work departure rate. Again it would be nice, if these metrics would be available out of the box.
(I teach Kanban courses BTW)
Something similar is required by DORA metrics: deployment frequency.
Which I assumed to be available out of the box in a product with "DevOps" in its name.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
During the past year, our organisation has began using Scrum. Over the past few Sprints it has become apparent that our Scrum isn't really working - we have difficulties with dependencies of certain tasks, and we are way off on our burn down charts.
Historically, we'd never paid any attention to our velocity and complexity of products, and everything was pretty much a guess.
We are nearing the end of our first Sprint on our new project. I have been working over the past couple of days of ensuring that we have a prioritized, complexity estimated product backlog. I retrospectively added the user stories that we are working on in the first sprint. It's quite apparent that we have bitten off more than we can chew.
We estimated our team velocity to be 28 story points, however, we haven't actually finished any of the user stories. Is our team velocity actually zero, and if so, how do I begin trying to plan the next sprint? Do we need to re-estimate our team velocity going into Sprint 2? Or can we take a best guess of what our velocity actually is given the percentage of the user stories we've actually completed?
Another issue we have is that our team is split into three tiers - Data, UI, and Services. This can make Sprints difficult to plan because of the different skill sets. For example, we have a very large user story which involved importing data from our legacy system (almost a whole sprints worth), but only our Data guys are able to work on this story, so we need to add additional stories which will allow the UI and Services team to also be involved in the sprint. We are then stretching ourselves even further.
Not many people on the team understand Scrum that well. I did a Scrum master course about 4 years ago, and I've forgotten a lot of what I'd learned, and I'm really struggling to get this Scrum team working well.
We have a scrum team of 14. Is this too big, should we try and have two smaller scrum teams? We are all working on the same project.
I'd be very appreciative of some advice from seasoned Scrum Masters on what we can do to try and help our Scrum process.
It sounds like the retrospective for this sprint will be interesting! These are some of the things that I might try and encourage the team to focus on in the retrospective:
Your velocity is unfortunately 0 because no stories are Done. I would encourage the team to consider:
What went wrong with the unfinished stories? What stopped them getting to Done?
Were the stories too large or complex? If so, how could they have been broken down? Beware splitting the stories into "layers" - stories should be split into vertical slices so each story still delivers an increment of user value.
Did the team start too much and not focus on finishing what had already been started (too much work in progress)?
You might need to remind them that the team as a whole succeeds or fails - if one part of the team struggled it was up to the rest of the team to support them and come up with a solution.
As discussed above, stories should be vertical slices of functionality, not horizontal ones. This is tricky because software engineers often think in "layers". How can you overcome this with the "tiered" team? In particular, how can you avoid hand-offs between the three groups (hand-offs are expensive and cause delays). Some thoughts:
Could the Data team have provided a stub (e.g. an interface that returns hard-coded dummy data) to allow the UI and Services teams to proceed while the data layer is being completed?
Could a cross-functional group have swarmed on each story (so all three "tiers" are forced to work together on completion of a story)?
How can the tiers cross-train so they can take on work outside their specialist areas (this is the concept of "generalising specialists" or "specialising generalists"). This will allow them to support each other when the going gets sticky.
Is the scrum team too large (probably)?
A "two pizza" team of 5-9 members is ideal
Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
Each scrum can work independently on an epic
Outside the retrospective, the scrum master and product owner might want to think about a couple of things:
Backlog management is really important (and really hard to get right) - it sounds like you have done lots of work on this, but it is vital to keep it up. A poorly groomed backlog will stall the team.
If you have silos (e.g. between the "tiers"), you need to work to break them down. Silos reduce the team's flexibility and create hand-offs which are expensive.
Finally, "Succeeding with Agile" by Mike Cohn is a really great book which covers the practical side of making scrum work in the real world. I found it extremely useful.
Bids has given good advice and what I consider the answer to the headline question but it is buried in there. I wanted to explicitly call it out:
Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
In Scrum stories are intended to be vertical slices through the system. You should restructure your teams so that they have the expertise to develop the end-to-end features. This will make a huge difference and I would try this before doing any other tweaks.
Not finishing any stories is pretty bad. You should limit the amount of work in progress.
I would recommend that you give the team only one story and make them work together on it. They're obviously a brand new team, that need to learn to walk before they run.
Would this be wasteful by not fully utilizing team members? Maybe, but the team haven't proven they can actually deliver anything. At least delivering one thing would prove a certain level of productivity and it would force them to actually work as a team.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I recently interviewed with a company which has started introducing Scrum for their development cycles. I asked one of the developers how their experience has been, and it sounds like they are completely divested from the planning process. He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Basically, at the start of the last Sprint (or two) he was handed a to-do list. He had to breakdown items into their respective tasks (so they could be worked on over the Sprint), but wasn't involved in any planning activities; I'm skeptical he was allowed much input into how much effort an item might take -- I suspect the architects decided this for the team.
Is this how Scrum should be handled? My current team fully participates in all planning activities, continually adding our input as to how features may be addressed and how much effort they might take. I'm a bit skeptical (and nervous) about a company which simply hands developers a to-do list without asking for their input.
Note: I understand that once a Sprint starts, the list really is a prioritized to-do list. My concern is not having input into the planning process from the start.
If those who are doing the work don't get to give input saying what amount of work can fit into a sprint and let the business decide whats most important and should be scheduled to fit. Its not going to work run away. They are using new trendy agile words but doing the same old things.
(...) He wasn't allowed any input as to what went into a given Sprint, and didn't participate in any planning or grooming activities.
Obviously, they're still doing command and control and micro-management (the team is not empowered and self-organizing) and they are still using push-based scheduling (they didn't enable pull-scheduling).
Scrum has other characteristics but the above points are more than enough to say that they aren't doing Scrum, regardless of how they name it, they didn't really shift from the outdated waterfall approach (they just did put some lipstick on the pig).
This is a big hint that they're still totally clueless about what Scrum is about, they didn't get it at all. And this is not going to change without some inspection and adaptation, if they even want to change. If you don't have the power to make this happen, run away.
Is this how Scrum should be handled?
No.
I worked at a place that called themselves agile. They had 6-8 month release cycles. Some things came from a backlog, but during the "Requirements Gathering" phase, basically the managers would spend a week or two meeting with various people in the company, and write up a feature list. The first day of each 4 week "iteration", the dev team would all get together and break down everything in a series of meetings. The last day of the iteration was deployment day, where there would be an intrim deployment that nobody outside of the dev team ever saw.
During the 8 month release cycle, the managers would touch base with the stakeholders maybe once or twice in the last two months of the release, at which point the only issues raised in those meetings that had a chance in hell of getting done before release were issues that were bad enough to make the whole effort useless if they were not implemented.
This is not agile, this is a variant on waterfall with a poor choice of ideas and methodologies cherry picked from other methodologies. At the end of the day, it still has all the same problems that waterfall does.
The lesson I took from my employment there is that development methodologies include things for a reason. If you are cherry picking from a methodology without fully understanding it (and by fully understanding, I mean having actually worked with it), there is a high chance that you will not use something that is actually vitally important to the whole thing. For example, in xp, kent beck advocates relying on refactoring later as a way to cut down on up front design. However, the only reason this actually works is that he also advocates TDD and pair programming. If you have a comprehensive test suite and an extra set of eyes there for the whole thing, refactoring is fairly safe. If you just cherry pick the first part and leave those two out, you are essentially cowboy coding.
I am extremely skeptical of shoppes that roll their own methodologies for this reason. There are an absolutely shocking amount of crimes being committed in the name of agile.
Is this how Scrum should be handled?
Definitely not. Scrum strives to increase transparency. By blocking developers from planning activities, they are doing the opposite of what scrum suggests.
You talked about 2 points here:
1. Sprint Planning - The Scrum Team members should be Definitely required here.
2. Backlog Grooming - May or may not be required here. You have to use your resources wisely and with common sense. One team member with strong developer background would be okay here I think.
There is one more type in Scrum:
Release Planning - Some might say developers are not needed here. But as per the Scrum Guide - "Release planning requires estimating and prioritizing the Product Backlog for the Release". Well prioritization can be done by the POs and suggested by the stake holders, but estimating would be most accurate if it is done by someone who is actually going to do the work, so it is a good idea to involve developers here. Again, resources should be used wisely. If it makes sense to not involve all developers and have people rotate turns to estimate, that is not a bad idea.
I suggest follow this structure:
Sprint Planning - part 1 : Estimation and pulling backlogs in Sprint from product backlog (PO, SM and Team are pigs here)
Sprint Planning - part 2 : Tasking, estimating task hours and breaking them down. (SM, and Team are pigs, PO is chicken here unless PO is taking tasks as well)
It is up to the team to figure out, during the sprint planning meeting, how it will turn the selected product backlog into a shippable product functionality. If they are not part of this process then they would not be able to commit.
The answer to your title question is: Developers (team) must participate in planning meetings. Planning meetings are for developers (team).
The good approach is to have two planning meetings at the beginning of each sprint: Planning meeting 1 and Planning meeting 2. In Planning meeting 1 Product owner gives prioritized (and size estimated - size estimation is not done on planning meeting) product backlog to the team and team starts to discuss most prioritized user stories. For each disucssed user story team should be able to collect:
Detailed requirements (for example which fields the input form has to have ...)
Constraints (for example how fast the functionality has to be)
Acceptance tests (verification of results)
UI sketches (for example how should UI flow looks like)
Acceptance criteria (validation from end user - acceptance criteria doesn't have to be real test. It can be something related to "easy to use" etc.)
There should be time boundary for Planning meeting 1. Number of user stories you were able to discuss can correspond to number of user stories you will be able to complete in upcoming sprint. At the end of Planning meeting 1 team must make commitment - say how many of discussed user stories will be done in upcomming sprint. Sprint planning meeting 2 is only for team because team further discusses user stories and breaks them into tasks.
Generally, of course they should. Obviously, it's never realistically possible to the degree that developers would like. However, if sprints are usually "Hair On Fire" type affairs, where the developers get no serious input at all... then at the very LEAST there should be regularly-scheduled "entropy reduction" sprints, where all tasks are selected exclusively by the developers for the purpose of cleaning crap up.
At least some developers need to be there so work can be properly estimated and pipelined.
But not all developers need to be there. All can be there is it makes more sense.
On the other hand, developers need to understand that the business priorities are the priorities, no matter what they think should come next. Everyone has to work together ot make it work.
I'm not so much worried about my input, but about my insight. I recently was involved in a project where I had no knowledge of the project before the plans were handed to me supposedly complete. The nightmare started when I discovered that the process was not completely thought out and the data definitions were not complete. I wound up having to go through the whole process again to get the answers that I required.
The Team can be involved in the planning process without a formal process or meeting. The planning process is really very fluid. At the start, the goal should be to get to starting sprints ASAP. Spending too much time in planning before the first sprint feels very waterfall and is a waste of everyone's time. I, as a team member would feel relieved to not be a part of that, except for the fact that it indicates a dysfunctional nature to the organization. The Team should always be free to voice ideas on an ongoing basis (since that's when the real planning happens). But, 2 things you mentioned concern me most.
First, the Team should be the only ones to determine how many backlog items they can do this sprint. They certainly would be involved in estimating the effort. That's a big problem.
Second, the Team does not sound like they have access to the product owner (maybe there ins't even one here). Even if the team has not been involved in the "planning" thus far, surely if I were talking to the product owner in the planning meeting, or had access to them at other times, I would voice suggestions over time.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
Given that the tasks in a specific sprint will not divide perfectly into the team, and all finish on the same date, what do you do to keep everyone working as the sprint moves into its final stages?
Inevitably it seems like there will be one or two people freed-up. If all the other tasks are done-done, and the remaining tasks are already underway, then what?
Do those team-members pick up items from the top of the product backlog, as they are likely to be needed in the next sprint anyways to get a head start?
What do you or your teams do?
My teams have always picked items up from the backlog, starting with the highest-priority items that can fit in the remaining time.
If nothing quite fits that criteria (as when there's only half a day left and/or no small stories to pick up), consider paying down some technical debt.
Scrum is done by teams.
If some people are done, they can help other members of their team.
They can also help their team by getting a head start on the next sprint.
They can also do some exploration of new technology, if that would help the team.
Or they could brush up their own skills, if that would help the team.
They could create training materials to help other members of the team improve their skills.
That's a team decision.
Pay down Technical Debt
Do anything that the team thinks should be done but doesn't belong on a card because there's no visible business value. Some people have called these tasks "technical stories". They tend to be things you should have done before Sprint 0, but didn't. Examples include adding of these that you don't already have to the build:
a Continous Integration server
a test coverage tool
static analysis tools
One thing I recommend is looking up future tasks and doing some detailed planning for estimates. This is non trivial and will take some time. Another is to scope of a new large scale project that can be broken into tasks and entered in product backlog.
Refactoring, writing unit-tests, improvement skills.
(...) what do you do to keep everyone working as the sprint moves into its final stages?
Nothing, I expect a self-organized team to find out this by themselves. And there are many options (by order of importance):
Help other members of the team to finish their stories (achieving the goal of the sprint is the most important, the whole team succeed or fail at this, not individuals).
Prepare a kick-ass demo.
Pick up a story from the backlog that can be done-done before the end of the sprint (i.e. not always the next highest priority items but something that fit in terms of size).
Repay technical debt if you have some.
Document things if this make sense.
Explore new things (tools, frameworks, testing techniques, etc) that may be useful for the team.
While it may seem obvious for team members to move on to the next highest items in the product backlog, I would advise against starting with this.
First and foremost, the teams' obligation is to achieving the sprint goal, so anything they can do to work towards that must come first (e.g. helping out testing, chipping in where possible, etc.).
Next, the team should look at expanding their definition of "done". Perhaps it currently doesn't include testing, or doesn't include some form of code review. Most teams starting with Scrum do not start with a definition of done that truly has a product increment that is ready to ship, so now would be the team to move towards that.
As others have mentioned, what tools do you need setup in order to get closer to a shippable state? Continuous integration? Automated acceptance tests? Now is the time to add these things.
Likely, you also have areas of the code that existed before you moved to Scrum and thus don't have very good test coverage or have accumulated technical debt. Now's the time to pay that off.
Also, as Mike Cohn suggests in his book Succeeding with Agile teams may want to reserve roughly 10% of their time for some look ahead planning. This may involve having a meeting with the Product Owner to discuss some up and coming stories for future sprints, breaking down larger stories into smaller ones, or for designers, perhaps doing some wire frames or mock-ups for upcoming stories.
Once you've gotten to this state, only then should you consider continuing on with the product backlog.
When there are team members that have completed there task early and find themselfs unoccupied there are a few things that can be done.
Make sure that estimation can be improved so hence planning can be improved. In doing this, bare in mind this estimation is very subjective. (However in my view underestimation is a situation we do not want to be in).
The scrum master has to bring in an ethos to the team of "Forwarding thinking"; improvements in oneself, in team productivity and the product or business the team is working on.
2.1. Try help out other team members task where possible to get stories Done (DOD) in the the sprint.
This could be pair work (pair programming)
As a programmer fixing other peoples bugs
etc etc
2.2. Try to help the scrum-master with other stories in he backlog. Check if any small story can be completed within the capacity of sprint making sure of it Impact to the sprint.
2.3. Work on research where there is a story in the backlog which is unclear. Do research on this story. Here a new story can be created with the emphasis on delivering research results. This story should be 0 points. programming prototyping etc can be done on the developers local PC without it being checked in.
2.4. Develop ones own skill either in there functional area (programming, testing etc) or the domain area.
The idea is a team that is performing. Each team member is dedicated to the goals of the team. So if you find yourself free...forward think how can i help the goals of the team.