I'm not sure what is unclear. From your own reference:
Throughput: The number of work items “finished” per unit of time.
So if you get asked: "How many units do you finish in an amount of time", this would be the obvious metric to make predictions. "We finish 5 units per day on average, so we should be able to finish around 30 by Friday next week".
An additional possible approach to consider, which could be taken alongside the admirable suggestions here to split up the feature, is to 'release' sections of the feature but with a 'switch' to allow the feature to be turned off, or only turned on for specific users/in specific circumstances when the first parts of this are released. This may help if you ...
As a Scrum Master your responsibility is to ensure your team is following the Scrum framework. The best way to do this is to explain the consequences of not following Scrum and how it will impact on the organisation.
Scrum talks about a potentially releasable Increment at the end of each sprint. The value with this approach is that:
You can get regular ...
In Scrum team works to provide the shippable product as an output of each Sprint. It is recommended to use the same timebox in each Sprint (1 to 4 week).
According to statement PM wants to put the feature in a separate branch and allow users to test for 1-2 months. Clearly, it's a product delivery from the Scrum team (assuming Scrum team already tested at ...
Your team produces a potentially shippable product increment at the end of each sprint. Whether this is then subjected to acceptance tests and actually being released is up to the client.
Of course, you split the big feature into product backlog items that can be handled within the Scrum framework so that it will take several sprints until it is completed, ...
I'm assuming you mean MVP (hope that's a correct assumption).
This article sums up what a good MVP should deliver well:
Serve at least one specific audience
Address at least one key problem
Have a well-designed User Interface (<- this feels open to interpretation)
Be easy to build and launch quickly
From that perspective, I could see building an ...
I’ve found that the Scrum Master role and the ADM role create conflict within the Scrum Team. Roles clearly need to be defined otherwise the Scrum Master position is compromised. The Scrum Master is task with protecting the team from outside and inside distraction. To me the ADM as I mentioned above can falls into this. Not a fan of this role.
I have some experience with migrations. What I can suggest is the following.
FIRST and very first, create a product oriented work breakdown structure. Don't do this alone, do it with the support of the team.
About the WBS, I'd put in the first level of my WBS the following:
Website: So you can decompose further the features to deliver (frontend, ...
As per scrum guide:
Monitoring Progress Toward a Goal
At any point in time, the total work remaining to reach a goal can be summed.
The Product Owner tracks this total work remaining at least every Sprint Review.
The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the ...
There's a school of thought that says:
Don't estimate bug fixes, chores and spikes.
This is because points should only be awarded to work that adds value to the business.
Developers should be given an incentive to complete the most valuable work. They get kudos for burning down story points because those stories represent direct business value.
Scrum teams can encounter external dependencies, but as you rightly say they often adversely impact on the capability of the team.
I would recommend that every time a dependency occurs, the team asks the question: "What can we do to avoid this kind of external dependency happening?"
There are several ways this question might be answered, including:
A Scrum Team should be cross-functional, meaning that they have all of skills needed to deliver a valuable feature to completion, which ideally means production. This means that a Scrum Team nearly never needs another team to complete an item. However, there are two exceptions:
1) Even though your team might be able to deliver a valuable feature, other ...
The direct answer to your question is that vertical slicing of user stories focuses on deliverable value in each story instead of layered stories that only deliver value when they are all done.
As an example, let's say you have something like this:
As an apartment resident, I want to file a request for maintenance online so that I don't have to wait for ...
As a decision of this problem can be the following steps:
Move the common code under some version control repo (git for example).
In the code of every projects (Android, iOS etc) add the link to the common
Get the last current version of the common code from repo for every projects.
Let's imagine that we want to update ...
Barnaby Golden's answer points to the trust associated with a product, which is very interesting and goes hand-in-hand with what Tom Graves writes in Product, service and trust:
A product represents the promise of future delivery of (self)-service,
via use of that product.
When we obtain a product, we trust that that product will deliver ...
This sounds like a primarily code-oriented problem. You want components of your application to be loosely coupled or completely decoupled. Using good programming principles like single responsibility and dependency-inversion, changing something in one system is not necessarily immediately impactful to everything else. From here, whether your common code is a ...
I like to think of a product as having a distinct set of end users who derive value from its use.
end users -> People that derive final value from the product, not people that will use the thing to make another thing (i.e. it is not a component)
distinct set -> Identifyable group of people get value from it, not 'the company' or some other ambiguous entity
The Product is the thing that you are building, or the service that you offer, or the need that you want to satisfy, or the vision that you have. The Product is first and foremost an idea "to do something". Only then you can you make it happen. And only then you can decide how you will make it happen.
Like putting together a Scrum team, for example. You ...
One of the golden rules of continuous delivery is:
If something is hard, do it frequently
At the moment you are concerned that releasing to the various platforms will impact on quality. If you can alleviate that fear then the problem goes away.
I would be looking to:
Use extensive automated regression testing
Integrate and test frequently (perhaps even ...
At scale, you might want to look at a Hierarchical Backlogs. This way each team can have their own manageable backlog to groom/plan but there's an overall backlog that can be utilized for things like increment planning.
Kenneth S. Rubin (author of Essential Scrum: A Practical Guide to the Most Popular Agile Process) has a good chapter about Which and How ...
I've seen team-specific backlogs work well where multiple teams have been working on distinct areas of a very large application. The fact that it got that large in the first place is more of an issue for software architecture, so shouldn't be an immediate concern.
However, that does also encourage silos..those teams know the areas of the product that on ...
Agile practices do have Team Leader or Technical Lead. But it's not necessary to actively recruit a new high profile technical lead, because among the agile team members who have vast experience on project topics might be someone to come in front and take the lead for specific project modules.
In my view, an agile team should have a Requirement Analyst Lead ...
According to this source, we can read the following
What is Net Promoter Score® (NPS)?
Net Promoter Score (NPS) is defined as a metric for determining the
state of a customer’s loyalty and satisfaction with a brand or
Classification of customers based on NPS survey response:
The data pulled from this response is an indicator of their ...
Perhaps you can send out a survey to all your stakeholders every time you do a release. This encourages more engagement than simply an email. There are a few very nice tools available to make surveys more fun.
Perhaps you can have a small banner at the top of the system (if this is possible) with a link to a page which explains the value delivered in the ...
In all my work as a Scrum Master and Agile Coach the one thing that always always impedes teams from becoming self-organising is meddling third parties:
e.g. 1: a manager that wants to micro-manage individuals on the team - this totally blocks any self-organisation happening e.g. engineering manager, architect
e.g. 2: a command and control product owner ...
If you have already started the sprint - i.e. its an active sprint and you want to see the 'burn-down chart' in hour instead of story points, then you can go to the settings of the board in Jira you can change the burn-down to look at hours instead of story points.
So you are saying that task 2 is blocking 1 essentially and you own both?
If this is what you are asking, then I would say if task 2 is a new piece of work that needs to be done and you need to do both pieces of work, it makes sense simply to move task 1 part back and finish task 2 first.
No they don't. A scrum master and an agile coach are both leaders but don't necessarily need technical skills to be effective.
I think it's useful for the members of the team to have varying levels of technical ability, some senior developers and some more junior ones but in my experience there doesn't need to have a designated leader if the team is a quite ...
I will answer your question with reference to Scrum.
In Scrum there are just three roles: Scrum Master, Product Owner and Development Team member.
There is no stated leader, which is done deliberately as leadership is seen to be distributed across the whole Scrum team. For example, when working on a particularly database-heavy project one of the team ...
The typical answer would be to ask the team. Many of the methods built around agility favor self-organizing teams, where the teams would assess the knowledge and skills that they have and determine if they are missing something important or relevant for the team to be able to do their work.
As far as methodologies that go that have a similar role, both DSDM ...
Is it realistically possible? Yes, I’ve witnessed it happen on several occasions.
The other answers make a good point about challenging factors:
An effective Scrum Master will need those things and also will need to know how to ask the right questions to get the right information out of the team. It’s an information game....
The real question is, can the team work remotely. Of all the roles, the Scrum Master is not more or less dependent on good communication than the other roles. At least not if they work as a team. Sure, you can lock a developer in a room somewhere and they'll produce code, but that's not what a team is. Teamwork only works with all the people in the same room....
Without understanding fully, I don't think we can suggest the best approach. With that in mind, here is my approach based on the information given.
1) Remove the concept of 1 week development, 1 week testing. It should be test as soon as developed, fix bugs as soon as it is tested. This will ensure that your deliveries have as little amount of bugs as ...
There are two major impacts of a remote Scrum Master in my experience.
The first is that meetings like the retrospective and sprint planning are a real challenge. The biggest problems are usually with audio quality, particularly if using phone lines or teleconference hardware that mutes the end of the call that isn't talking. If you can get a top quality ...
Is this regular? As in more than 5 sprints in a row? If yes, then you should help the team improve their estimation. And this is to ensure that they are fully capable of estimating properly.
If they are still estimating higher than expected, that's a good thing. This means you have enough buffer to deal with unplanned problems like additional work, change ...
Your user stories should be rewritten from user's perspective, not technical team's perspective. See below.
US1: as an admin I want to write a message on a new page dedicated for this matter.
As an ...
Does it make sense if I impede task 1 under my name?
Yes. No. Maybe. It depends.
In general, Kanban is about flow. If your unit of work is a task, rather than a user story that represents a vertical slice, then it's certainly possible for a task to be blocked for any number of reasons. However, a task isn't inherently "blocked" simply because ...
The concept of you impeding a task doesn't make sense, conceptually. An impediment is "a hindrance or obstruction in doing something". I highly doubt that you are obstructing yourself from completing the planned task. However, the bug that you found can be a hindrance or obstruction. I would refer to the existence of the bug as the impediment. If the bug ...