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
How can I deal with sprint backlog items that somehow becomes obsolete or unnecessary mid-sprint? Do I mark them as solved?
What about tasks that are dependent on external factors outside the control of the team?
The Scrum Guide covers this eventuality:
During the Sprint:
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
So, if you end up removing Sprint Backlog Items, your first action would be to return them to the Product Backlog. You don't mark them as "Done" because they're not, and to do so would reflect incorrectly on the Velocity.
Having removed Sprint Backlog Items, the Development Team may feel that they have capacity to bring other Product Backlog Items in to the Sprint. That's their call.
Later, perhaps during Product Backlog Refinement, you may decide that the removed Product Backlog Items are no longer useful. You could then remove them from the Product Backlog, updating any Product Roadmaps or Release Burndowns that had included those items.
I assume that by sprint backlog items, you mean what is also called tasks, or the breakdown of the product backlog items, as done by the team during the planning session. Just throw the card into the nearest recycling bin, or mark it as removed from a computerized system. You may mark them as solved if that makes sense to you (if by solved you mean no remaining work to be done).
If this happens often, then your team may wish to bring this up in a retrospective. It is an indication of the team not having a clear idea of what needs to be done - either due to insufficient planning, an impaired idea of what the product backlog item is, or possibly changing requirements. You may wish to bring it up with the PO if it is the latter.
With regard to tasks dependent on external factors - you should plan your work accordingly. Separate the high risk components from the low risk ones. have your existing (and low risk) modules interact with the high risk components through interfaces, and design the APIs to have as little of a risky surface as possible.
When building the low risk module, you should stub (mock) the high-risk modules, and you will be well served using dependency injection so that you can then easily swap the stubs for the real thing when the external factors become available. If the external modules do not fit your interface, write an adapter to transform your calls into the external module's APIs.
Even if the external factors are available before you build your software, you should consider doing the above, though developing a stub is not as crucial as it would be if it wasn't ready. Doing this will safeguard your system from future breaking changes to the external components.
Either way, your plans should account for this, and you should communicate the problem to the PO. He will not be able to release any PBI that is missing a crucial part.
Related
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
When and who undertakes the work to sufficiently gather answers so that we can start to write stories for an upcoming sprint. Is this work done continuously and in parallel to existing sprints by the product owner? I guess this then creates tasks for a sprint such as investigate x and y. What if the PO suddenly requires a developer to answer some of the questions by trying stuff out? I understand the idea of spiking and creating r & d tasks. I guess I want to avoid the main dev of a feature being delayed to a following sprint too often.
The team determines how much new story work it can do during a sprint. The amount of time they have to do that work is some percentage of the work day. Depending on the responsibilities of team members (customer support, bug fixes, emails, PTO, other duties) that amount varies from team to team. I like to see 10-15% of the work day dedicated to "planning" for the next sprint. That includes helping the PO research, writing stories, breaking up stories, design sessions, what-if scenarios, etc. I think the key is not to shoe-horn every one of these types of tasks into a sprint but rather to set the correct time allocation to doing the sprint work. Maybe something like 30 hours/wk is an average number.
So to directly answer your question; the planning work is done in parallel to the current sprint work.
We usually have one or two meetings to talk about future stories. Also, we reserve some overhead time in each sprint to check out things we need to know to start a story. The meetings help determining which stories will probably shop up in the next sprint, so we know which questions to get answers to during the reserved time in the current sprint.
For us, if it's a large project, we will have kickoff meetings to brainstorm the project. There is often a knowledge gap for PO's between what they want to do and what they don't know we can do that these meetings can fill.
When new stories are created, we try to assign story points to them at some point before the next planning meeting so the PO has time to prioritize the list before that meeting.
I'm not sure of the kind of situation you describe where a PO would "suddenly" need a dev to try stuff out. In that case, I would offer a spike in the next sprint. Generally using new technologies isn't something that happens every sprint so this should suffice. If not, perhaps the sprints are a bit too long for this purpose (a trade off to be considered at least) Another alternative would be to introduce an evergreen story for trying stuff out. I've seen teams have these kinds of stories for tech debt payback - you could off an either/or situation. Sometimes dev fixes tech debt, sometimes they try stuff out. And if you run out of tech debt somehow, you can always grab another regular story to put in its place.
We typically reserve a sprint or two after a big release for research and proof of concept stories. Doing research as part of the regular sprint seems like it would be problematic. You'd probably use that time to absorb mis-estimations for value-adding stories and end up never using it for actual research.
If a new story drops into the backlog that needs research and the PO runs it up to the top of your backlog then the team should include some research time into their actual estimate. I would only do that if I didn't have the luxury of a research/prototyping sprint ahead of time though since estimating research can be a bit nebulous.
Who: Product owner. Stories and Product backlog are his responsibilities. Product owners are generally experienced people; even if they are not technical they can certainly perceive implementation complexities at abstract level. Still, if a story has gray area PO must ask right people the right question. He can ask developers, testers, peers, clients and even scrum masters.
When: all the time.. Continuously. PO must not do anything but (1) provide (or get) answers for the team’s questions regarding scope and function, (2) and gather data that would refine the stories and their scope: thus proactively solving the queries of his team.
Bottom line is if product owner is not giving good stories to the team then he is not doing his job. Stories can be written by anyone but in the end it’s PO who ensure that Product Backlog is in order and that top priority stories are defined.
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
We use scrum with our development, we often create task/ticket for developer, and I want to find a way
to record them. But I hava a refused question, that is one way to record them. one way is write on
whiteboards, the other way is write on Agile project management tool(Pivotal Tracker), I think they
are duplicate， so which is better?
It depends who cares about the tasks.
In teams very new to Scrum, devs can split stories in to tasks to get a better idea of estimates, collaborate on work, etc. For this reason, whatever the devs prefer should be the way forward. Usually a dev will prefer to put tasks on a card, or a whiteboard, or something close to the workspace, but some devs do prefer electronic systems. I find the act of moving a card or writing on a board gives a sense of commitment to a task or story, so I prefer this.
Sometimes the PM prefers to have the tasks so that he can see if a story is 65% done, etc.
Every single time I've seen this it ends up with the PM telling the devs off for not finishing their stories when they said they would, or saying, "It was 85% done yesterday! How can you not have finished it?" This happens a lot with new teams, where devs often prefer to do the easy bits first, or they don't know how to integrate their work with others' yet.
The thing is, there is no value whatsoever in the tasks! It's only possible to get useful feedback by delivering the stories, even if they don't represent completed features but just slices through the system. The tasks themselves are only valuable for the iteration until the stories are completed, so no historic record is needed. PMs who value the tasks often end up with part-done stories and nothing to release or showcase.
For this reason, I would try not to duplicate the tasks for my recording efforts, but just to let the devs make the tasks themselves and put them wherever they want to. It's easy enough to count tasks manually for a burn-down.
I'd have to disagree with the previous answer of there not being any value in the tasks. I myself prefer the electronic methods such as:
- Calenders : Not only do they say what needs to be done but also when and how long it might take
- Task List : Just like the traditional todo list.
- Scope Items : Turning the items in the scope spreadsheet into deliverables.
Having physical tasks on cards (tried that) or on the whiteboard in the LLP (did that for a while) is technically better, because you're able to always get to the information quickly. However if your development team is distributed, especially when then PM is in another part of the world, you're going to end up having to duplicate data electronically. The tasks themselves add value to the development house in that they provide good historical data about how long certain tasks take. This information is extremely valuable in building the Scope Matrix of future projects, and as such affect the costing and delivery time. As a side benefit, you'll be able to see by historical trend which asset (i.e. developer) is able to perform and at what efficiency. E.g. If you give a developer a Database task to do and they were inefficient then you'll know next time that database tasks should either be given to someone else or during the down time between projects, said asset should spend time upgrading the database skills.
So important is historical task recording that sometimes clients will ask to see the tasks and how long they took as verification of "the bill". When clients are charged by the development house's hourly rate for work, they want accountability for every hour (or part there of) spent. We used to fill out these sheets with the tasks and the durations to send along with the invoice to the client; and sometimes they would question it.
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
In Scrum, it is obvious that we could produce a demo after each sprint.
I don't know how to produce demos in Kanban since it doesn't has the sprint concept (I may be wrong).
Would you please enlighten me regarding how to make releases in Kanban?
Thanks for help and time.
When we were implementing Kanban at my last job, the releases went one of three ways:
Release every two weeks on a schedule.
If enough sticky notes end up in the "done" bucket on the board to merit an out-of-cycle release, notify the business unit that we're releasing so we can prevent getting too out of sync.
The business unit requires an out-of-cycle release for a specific feature of set of features that are needed immediately.
It was pretty open-ended, really.
Kanban says how to manage the flow of work and limit work in progress, it doesn't say anything about the frequency of releases as such. However, it is quite demanding because it demands that a working integrated version of the product be kept at all times with new features added as soon as they are considered complete (done, last column on the board).
A concept that is frequently used is that there is a "cadence" - a regular interval when this "ready product" is taken and actually deployed to the live system/shipped.
However, I think that one concept that is very clear in Scrum may also help here. In Scrum it is clearly said that Scrum calls for a "shippable product increment" (confirming to the definition of DONE) at the end of each sprint. Whether to actually ship it / deploy it is out of scope of the development process, because it is ultimately a business decision. Same I think applies to Kanban, a ready, integrated product is available at all times, whether to actually use it as a business decision which is outside of the scope of the development process and its management.
There is no single definition. Usually in Kanban we add MMFs (Minimal Marketable Features) which, by definition, means that every feature should add value to the customer, thus you should be able to release every feature independently.
This doesn't mean you have to release each feature separately, so you will find whole range of approaches (David mentions a few of them). I find it a common case that Kanban team release more often than they would if they followed one of time-boxed approaches.
Demos in Kanban are optional but if the client is willing to have them you can demo features as you deploy even if you release every feature independently. In theory every feature should add value so this approach should work well.
We make a demo a condition of moving a feature from "Testing" to "Ready for Release". So it's feature-by-feature rather than sprint-by-sprint, and the nature of the feature will determine the nature of the demo. The greater the business involvement during development the less of an issue this becomes anyway.
You can try adding a sign-off step to your DOD where you may arrange a quick demo. But the difference would be, it will be an one-to-one demo whereas in scrum sprint review, the demo is for all the attendees.
Regarding the release cycle, its already mentioned in previous answers. I would like to add one more point, you may have a limit for yet to release items. For example, if you have 10 MMFs are in the board ready-to-be-released then release process can be kicked off then and there.
This method may help you to track down throughput in a way.
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
What are the reporting lines when using SCRUM methodology as compared to a "tranditional" matrix organisation where developers report to development managers, project managers and any other stakeholder at the time?
The point of Agile is to eliminate all the "reporting lines" and pare things down to the essential relationships and nothing more.
Scrum teams are intended to be self-organizing, not have organization imposed on them.
I don’t believe it is the intention of Scrum to define any reporting lines whatsoever, at least not in the formal context. It’s a software development methodology, not an organisational structure approach. Although I often play the role of a Scrum Master and my direct reports do the development, we could conceivably operate with one of the other guys playing the lead role and myself being a developer without it being contrary to the formal construct. Of course this could be interesting in the event of a dispute but for the most part I think Scrum and reporting lines are two independent concepts.
The reporting lines within a Scrum project are dependent on the situation. At a high level the reporting lines for the project might look like this . . .
Team member => Team => Product Owner => Customers/Sponsors.
The team members are accountable to each other, and as such at the very least use the daily standup to bring their team mates up to speed with any issues and problems. Between them they will decide on course corrections, or a plan of action to fix the issue. The ScrumMaster is part of the team, and may decide to take on tasks to facilitate the removal of any impediments that the team runs into, but that does not mean that the team reports to the ScrumMaster.
The team also makes a commitment to the Product Owner (PO) when they agree on the goal and deliverable for the sprints. As such they will allow the PO to provide leadership for the project and let them (the PO) resolve any issues with respect to the clarification, scope of features.
The PO was the original champion for the project and managed to get funding and buy-in from customers and sponsors. As such the PO needs to keep those stakeholders appraised of the projects progress against the plan for delivery and success. The PO needs to ensure that the stakeholders remain satisfied and in the case that something unforseen occurs, confirm that the new plan still meets with the stakeholders buy-in.
My final note is that managers and project managers are still involved, though more indirectly to help the team remove and solve their impediments that are inhibitors to their success.
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
We've been using Scrum on a few projects now with varying success and I now have a query relating to documentation.
In Scrum, you obviously have the product backlog ("The application begins by bringing up the last document the user was working with.") and the sprint task backlog ("Implement forgot password screen"). However, in all the examples I have seen, these two items are fairly high level in terms of detail (being designed on fit on a post-it note).
So, where does the detail sit? Let's say the client has some very specific requirements for a stock management screen, or has a complex API that needs to be integrated with on the back end, where is this documented, how and who captures this information? Is it seperate to the backlog but populated on a just-in-time basis or some other way?
Sprint backlog
The sprint backlog is a greatly
detailed document containing
information about how the team is
going to implement the requirements
for the upcoming sprint. Tasks are
broken down into hours with no task
being more than 16 hours. If a task is
greater than 16 hours, it should be
broken down further. Tasks on the
sprint backlog are never assigned,
rather tasks are signed-up for by the
team members as they like.
Detail can sit in a wiki available to the whole team and editable by the whole team.
Not sure if this is as simple as it sounds. We've seen challenges with the detail part as well. Lets say if we're developing on a story that requires capturing simple contact information for lets say a CRM system. I now have the stories from the PO and we went through the sprint planning meeting and understood the first 5 stories that meets our velocity. However its always a struggle on capturing all the details of the conversation, for example how the screen needs to be laid out, what are the 20+ fields you need to have on the screen, can some of these fields lookup information from other tables/views etc.
Who captures those details, should it be the PO or developer and whats the best practice for storing these details. We're right now trying to use wiki's for this, however it becomes an overhead in trying to maintain the action items on who needs to update which details and by when.
My understanding is that specific requirements such as this are handled by the product owner. They will liase with the client during Sprint Planning 2 and update the tasks with specfic requirements as needed - hence why the Product Owner is a optional attendee of the Sprint Planning 2 meeting. This gives you a hybrid of Just-in-Time and Sprint Planning 2 population of the specifics. Anything that isn't satisfied by the time you come to work on the task will be an impediment and should be dealt with a the daily scrum, by the product owner.
As the development is Agile when using Scrum you shouldn't find too much of an issues getting requirements just in time.