Test Management

• R

  What is the resulting priority between Impact x Effort and Urgente x Importance Matrixes?
  prioritization matrixed resources • • rosemadder  

  2
  0
  Votes
  2
  Posts
  0
  Views

  K

  These two matrices serve different purposes. You may apply the urgent x important (Eisenhower) matrix as a "filter". Worth recap some concepts: Urgent is something that cannot wait Important is something aligned to one's goals With that in mind... You'll always focus on urgent + important (do now). Hopefully, there isn't many items here (if everything is urgent, nothing is urgent). Once you cleaned the 1st queue is when you'll look at not urgent but important (do later). This is where most of your items will appear. Urgent items that are not important should be delegated to someone else who considers them important Not urgent nor important should be eliminated Once you apply this filter, you apply the second matrix to "fine tune" the priorities based on their effort x impact.
• C

  Can epics, features, user stories, span multiple releases or iterations?
  agile • • courtlanda  

  2
  0
  Votes
  2
  Posts
  0
  Views

  S

  It depends on how you define "feature", "epic", and "user story". The only one of these terms with anything close to an agreed upon definition, and even that isn't necessarily widely agreed upon or close to being a standard, is user story. The current thinking is that a story should, more often than not, represent something that is achievable in a few days of effort. If you're using iterations, they probably last more than a few days, so a story would probably not span multiple iterations unless it was started at the end of one iteration and finished in the next.
• M

  Flexible Kanban with JIRA
  jira kanban kanban board • • magpie  

  2
  0
  Votes
  2
  Posts
  0
  Views

  C

  You can't do what you want, and I'm not aware of any plugins that enable the functionality. The columns in the Kanban board are supposed to be an abstraction of the workflow, especially over all of the different workflows for all the different issue types on the board. Each status can only be in one column. I'd say that your more detailed workflow steps should probably be states for the issue and work on having less granular columns.
• 

  How to manage tasks from various project management tools?
  product management • • Alberto  

  2
  0
  Votes
  2
  Posts
  0
  Views

  C

  You do not mention your relationship with these clients, which is a key point to define what could be done. If you're a consultant intended to deliver more value to your customers (usually through software delivery contracts), you may have an opportunity to partner with them and deliver beyond software - deliver best practices (specially for people still not using task tracking software). If you're a partner and you have no influence whatsoever, then you may want to consider connecting these different tools into a task tracking software in your side through APIs, this way you'd have a consistent view from your end regardless of the madness on the other side. Now, about do this manually: If someone starts doing this manually as you suggested, this should be just to validate the hypothesis that having the information in a single place will really deliver value for your company... not a long term solution. See this person as as band-aid. The longer you take to remove it, the more it'l hurt.
• B

  How to track progress for non functional activities
  progress report • • baileigh  

  2
  0
  Votes
  2
  Posts
  0
  Views

  

  TL;DR Classifying testing or security as https://en.wikipedia.org/wiki/Non-functional_requirement may or may not be appropriate for your project. Regardless, all work related to a project's expected outcomes can and should be decomposed into estimable work items that are either "done" or "not done" when evaluating progress or deliverables. How to Manage Outcome-Based Delivery for Testing, Security, and Other Activities Even if they are classified as "non-functional" requirements because they are not product features in the way that many product or project managers typically think about these things from a development-focused perspective, they are still work and should be tracked accordingly. All of the things you mentioned should have measurable https://en.wikipedia.org/wiki/Performance_indicator and https://en.wikipedia.org/wiki/OKR , or at the very least desired outcomes for each activity. If they don't, then you're either not involving the correct subject matter experts in planning, or your project is doing things that were not (and perhaps still are not) appropriately defined at the strategic or tactical levels for the project. For example: For "performance testing" to be successful, what components will be measured, how will the measurements be evaluated, and what is the minimum level of performance that must be met? If "anomaly testing" is performed, what methodologies will be used and how many anomalies (or classifications of anomalies) will determine of the overall result is satisfactory or not? If "security testing" is performed, what are the standards or other baselines that need to be met to report success? If these things are gating criteria for the project, then they should be part of the "Definition of Done" and tracked as work items. If they aren't, then this would appear to be some sort of post facto scope creep. In the former case, these items should have been part of your project initiation and planning; in the latter case, the work items should be treated as new requirements within whatever change control processes have been established for the project. Involve Subject Matter Experts In either case, you clearly need to involve subject matter experts (SMEs) for the activities that are not accurately reflected in the current plan. The SMEs should ideally be the people who will actually be doing the work, or you risk a mismatch between abstract estimates and the knowledge and skill sets of the actual task performers. The SMEs can help: define the work required to meet each outcome or objective, identify how the work will be tracked and measured, and estimate the level of effort or time it would likely take to perform each activity within a clearly-defined set of assumptions. In other words, these things should be planned, estimated, scheduled, and tracked the same way you would track any other project-related requirements. The only difference is that it seems like the project currently lacks the required expertise within the team as presently constituted. That means you'll either need to add those people and skills to the team, or leverage outside resources to help the project fill any gaps.
• K

  Is there any place where one could observe real project ceremonies such as stand ups, retros, planning?
  scrum agile project team • • Kadir  

  2
  0
  Votes
  2
  Posts
  0
  Views

  

  I doubt that you'll actually find 'the real thing' (because who wants to share their development details?) but if you search for relevant terms on YouTube you find material that comes close. E.g. searching for https://www.youtube.com/results?search_query=daily+standup has a result https://www.youtube.com/watch?v=q_R9wQY4G5I , which gives you a pretty good impression of how a daily standup can/'should' go (It's a training video where they discuss what's going on). As is clear from the title, this one is part of a small series https://www.youtube.com/playlist?list=PLBF7FCBE7E2ECF1FB Happy hunting for other videos...
• C

  What are valid reasons for increasing the story points for a user story during or after a Sprint?
  agile estimation user stories story points • • Cleofas  

  2
  0
  Votes
  2
  Posts
  0
  Views

  S

  TL;DR: Don't mess with story points. They are an estimation tool, you use current knowledge at time of estimation to come up with a number. Any unexpected delay may cause you to deliver less than was initially planned, that's ok. You could not anticipate it, but you should not retroactively change your estimate. After your sprint is done, you will use the total number of story points of completed stories to update your velocity, so your next sprint can be planned based on better numbers. Maybe your velocity goes down because your IT operations department is having issues delivering the service quality that you expect? Maybe someone is sick? By adjusting the velocity you take this into account for the next sprint. However, the story points already assigned to stories in the active sprint must not be touched, because that would occlude the actual issues at hand. You may modify story points for backlog items when you learn something about the story itself which indicates that your initial estimate was likely wrong. But you should not include external factors that are completely unrelated to the story itself, especially not ones that you can't know at the time of estimation. When you find that particular kinds of stories consistently take more effort than you estimate (maybe because you underestimated the bureaucratic work involved in getting a new server VM commissioned) you can use that knowledge to make better estimates in future.
• R

  When a development team doesn't want to go through an OKR exercise
  team management okr • • Rossere  

  2
  0
  Votes
  2
  Posts
  0
  Views

  R

  A good way to bring the team together is to understand how is it affecting them. You mentioned there was no system in place before the OKRs. How did this affect them in their day to day? What problems have they encountered as a result of not having a system in place? That could be a starting off point to rally them behind a cause and then move on the idea of a solution to these problems: OKRs
• 

  RACI Accountability: How to get alignment when 2 teams feel they should be the Accountable?
  requirements roles • • emmalee  

  2
  0
  Votes
  2
  Posts
  0
  Views

  A

  I would try an exercise like this: Ask the teams to imagine a newspaper headline. You could actually mock one up if you like, but possibly just imagining it is good enough. The headline reads: "[Your Company]'s Digital Transformation Project Misses Every KPI" Sub-headline: "Director Fired" Ask the teams to discuss which director they think should be fired, and why. My hunch is that this should bring some clarity to the question of who should be Accountable.
• G

  I'm searching a motivational video about building an MVP in an agile approach on site at a shop
  agile motivation • • gionna  

  2
  0
  Votes
  2
  Posts
  0
  Views

  E

  I found that this video does a good job of explaining MVP: https://www.youtube.com/watch?v=0P7nCmln7PM This related article goes into more detail regarding MVPs. There are also great examples of how popular products started out as MVPs. This might be motivational to your team. https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp
• K

  Should PO define execution order of stories in a Sprint?
  scrum agile • • kalena  

  2
  0
  Votes
  2
  Posts
  0
  Views

  K

  No, the Product Owner shouldn't be defining the execution of work during a Sprint. At the Sprint Planning event, the Product Owner and Developers collaborate to craft a Sprint Goal, select Product Backlog Items for development, and the Developers create an initial plan for achieving the Sprint Goal and delivering the work. These three elements are the Sprint Backlog for the Sprint. The Developers are accountable for the Sprint Backlog. The plan is created "by and for the Developers". Although the Product Owner is involved in crafting the Sprint Goal and influences the selected Product Backlog Items based on ordering the Product Backlog, the Developers select the work, create the plan, and revise the plan at the Daily Scrum (and more frequently, if necessary). If the Product Owner is exercising control over the Sprint Backlog and the daily work of the Developers, that could indicate micromanaging and perhaps a lack of trust. It also indicates that the team is not self-organizing and self-managing.
• S

  4 people, 4 unrelated Tasks. Each person gets one task, based on preferences
  project team task management tasks • • Saumya  

  2
  0
  Votes
  2
  Posts
  0
  Views

  B

  You could see this as an optimization problem, and there are several possible fitness (goal) functions. For a truly satisfactory solution, you might consider a "satisfaction" value for each task/person pair, and optimize such that either total satisfaction is maximized (on average, everybody performs the task they're most happy with), or individual dissatisfaction is minimized (nobody is significantly unhappier than the other ones), or some other complex function. For small numbers of tasks and performers, enumerating all permutations is quite feasible, as is evaluating the fitness function for each and selecting the best solution. However, as Todd Jacobs rightfully pointed out, just letting the people come to a solution on their own might be best if they can be expected to consider fairness towards each other. Algorithmic solutions aren't always the best solutions.
• A

  how to split a story with cascading side effects
  scrum agile • • amarantha  

  2
  0
  Votes
  2
  Posts
  0
  Views

  R

  First of all, https://pm.stackexchange.com/questions/26881/how-to-chose-the-right-perspective-in-user-stories . It's useful to capture a requirement from a user's perspective, but then it starts to get in the way when you start to think at the actual solution that you have to build and all the technical implications, because doing things like API changes, schema changes, etc. is not something a user cares or even thinks about. You can start with a few user stories that reflect what the user can do when you move from one book to multiple books, and then see what might be required in each case and in what order you might do them. Then, https://pm.stackexchange.com/questions/27476/making-backlog-items-independent-how-that-can-be-achieved , it just means you should try to reduce dependencies as much as possible. You will always have dependencies and features that build on each other, you just have to be mindful to not develop with too many dependencies at once (more dependencies, more problems; less dependencies, less problems). It seems you already identified the kind of changes that are needed. Now it's a matter of deciding on the order. And you decide on that by asking "what is some small change that I can introduce to keep everything working the same?" You could change the schema for example, to support multiple books. One book fits into a schema that supports multiple books. All layers above it that store and retrieve one book, don't really need to know or care that the schema could now support more. Nothing changed for them. Then you might change the export to export more books, but because nothing else changes, you will still be exporting just one book. Import will work the same because of that. Then you change the import to handle more books, and things still work. They work with one book still but now schema, import, and export are prepared to handle more books. Then you think "what is some small change that I can introduce to keep everything working the same?" You get the idea. At some point you will be making the changes that actually handle multiple books and everything you've previously built is there to handle them. So that's how you split them. The fact is that, even if you build everything in a big bang effort on a separate branch, and then replace everything in one move, you will most likely still build it in a similar way. You might pay less attention to making sure things still work after each change, since you are building things on the side, in isolation, but order and dependencies of each step might be similar. The advantage of building incrementaly is that you find out about issues earlier than with a big bang approach, where things either all work, or don't.
• N

  What is bad to have sprint review before finishing sprint?
  scrum sprint planning conflicts sprint review • • Nykeriab  

  2
  0
  Votes
  2
  Posts
  0
  Views

  R

  There's no requirement that the Scrum events that bookend a Sprint - the Sprint Review, Sprint Retrospective, and the next Sprint's Sprint Planning - all happen consecutively. Especially for the Sprint Review, it's important to schedule that at a time where the key stakeholders are able to be present and participate to synchronize and coordinate with the Scrum Team. For the Scrum Team, having all of the events consecutively can be grueling and tiring, considering the maximum timeboxes of 4 hours for Sprint Review, 3 hours for Sprint Retrospective, and 8 hours for Sprint Planning. There is value in having time for the team. Ideally, I try to have this time fall between Sprint Retrospective and Sprint Planning. However, this time isn't for development, but rather refinement. The Sprint Review and the Sprint Retrospective can generate work for the team. At the Sprint Review, the Product Backlog is adjusted, which may result in unrefined Product Backlog Items being moved up or new Product Backlog Items being added. At the Sprint Retrospective, the team identifies changes and improvements that may require effort to implement. Spending time to refine the post-Sprint Review Product Backlog and the improvements from the Sprint Retrospective would be a good use of the team's time and make the upcoming Sprint Planning more effective. Beyond refinement, holding time for non-developmental work at the time around the boundaries of a Sprint can help the team include overhead activities (like company-mandated training) or just take some regularly time off to help the team maintain a sustainable pace (a principle of Agile Software Development). In your particular case, if I were coaching the team, I would suggest that the team build their Sprint plans around making sure that the Sprint Goal is achieved prior to the Sprint Review. Any other work that will be done within the Sprint should also be done prior to the Sprint Review. Any time outside of the Scrum events between the end of the Sprint Review and the start of the Sprint Planning session would not be on building the product. Instead, I'd suggest that the team focus on refinement, training, skill building, or resting.
• D

  Our scrum product team is ready to release, but releases are delayed by the creation of training materials and business documentation
  scrum agile • • derk  

  2
  0
  Votes
  2
  Posts
  0
  Views

  J

  This is something that's a problem for my organisation. Here are some things we do to make it less problematic: Use a Release branch in source-code management (including the sources of documentation) so that future feature work can be committed and tested on the Develop branch without needing a full code freeze. Regularly review the team's Definition of Done (either as part of Retrospective, or as a separate activity) to discover activities done for release that could (should) be part of a feature ticket. Begin each story by having a Start-of-Story Conversation between the developer taking responsibility for the ticket and one or more other team members to identify what testing, documentation, policy update, approvals etc. need to take place as part of the story. This is also a good time to consider other impacts of the work, such as likely risk areas for regression. Perhaps your policy updates and training can't actually happen until your product is released. But having prepared these as part of feature work, then the release activity is reduced to gathering together all the prepared pieces for the features actually included in the release and packaging them for delivery. Don't expect the Definition of Done to be perfect after your first time updating it - my suggestion to regularly review is important. I'd suggest that you have this review after each of the next few releases; you'll find work that could have been done earlier, enabling you to release with less overhead (more accurately, with that overhead moved to be part of the feature work, getting you nearer to the ideal of release on demand). Our Start of Story Conversation uses a template in our team wiki, that has a checklist of things we should examine to double-check that the story is Ready, and that all the risks and supporting work are considered before starting development. It normally takes 2-3 developers around five to ten minutes to walk through this and arrive at a shared understanding of what's included in a story, and what needs to be complete before it can move from one state to the next. Again, it's a living document, and the items in the checklist will be specific to your team and updated as you discover (in Retrospectives) oversights that could have been asked about before starting. (Actually, we choose one of several documents because we work on more than one product, and we have an additional one for non-product work such as infrastructure updates). We still need "release sprints" in our team, but that's an improvement from taking two or more sprints to release, and we're still finding ways to move work to the left, so we haven't reached our limit as we aim to be able to release on demand.
• R

  How to make my team follow the Scrum methodology?
  scrum team management scrum master conflicts • • rosemadder  

  2
  0
  Votes
  2
  Posts
  0
  Views

  E

  Scrum is about collaboration, trust and empowerment. It is going to be very difficult to make people do those things. They have to want to do them. Some things I would suggest include: Try and build up trust - perhaps by giving them good advice or by being an effective facilitator of their meetings Spend time coaching - try to get them to understand why they would benefit from following the Scrum framework Use the retrospective to hightlight challenges the team faces Introduce them to teams that are successfully using Scrum If you do decide to speak with your managers, ask them to motivate the team to be more agile. Perhaps by setting agile objectives (e.g. "Demonstrate a good Scrum process") and rewarding them if they do this well.
• K

  How to keep track of tasks that I remember?
  product management • • kalyn  

  2
  0
  Votes
  2
  Posts
  0
  Views

  J

  The answer is very simple: don't keep them in your mind. People can remember about https://www.simplypsychology.org/short-term-memory.html at a time, so when you try to remember more things or for a longer period of time, you usually have to revisit them mentally just so you make sure that you haven't forgotten some. And this takes a mental toll, makes you tired, and distracted. In my day time job I help and support a few development teams, which requires me to be involved in many topics at the same time and switch between them fast. What you described happens to me also. I need to clarify something, I need to send an email, I need to reply to an email, I need to setup a meeting, I need to test this feature, I need to check the database records for that other feature, while I deal with one thing, something else comes up, etc. How do I keep track of these things? Write to disk! I keep a backlog of things I need to do. It's just a text file where I drop things I don't want floating in my mind. For example, while I'm verifying some database records I may remember to send an email regarding some other topic. If I try to keep that in mind and also focus on what I'm doing, it adds strain. Do that with a few more things and it becomes very tiring. So when I remember something, I add it to my backlog in the file and forget about it while focusing on what I'm doing right now. Then, when I'm done and I get a breather to start something else, I just go to the file and pick the next topic I think it's important. Once done, I delete it from the file. Each morning I try to plan my day by organizing the items in the file and putting first the things I want to work on for that day. This way, I don't need to remember many things because they are written down. Then rinse and repeat. Place the file on OneDrive, Google docs, or some place else online with easy access and backup, and you don't even have to worry about the file itself.
• 

  Developer -> Product Owner - what skills should focus on in order to make the job transition?
  product owner • • briley  

  2
  0
  Votes
  2
  Posts
  0
  Views

  T

  The ex-developer must resist the urge to develop If they continue to develop code, they are likely interfering with the product developers, possibly tend to micromanage, and above all keep their head stuffed with development thoughts while they should be communicating with the various party and structuring the insights gained. Apart from that, as Nezih Tinas noted, deep knowledge of the product is an invaluable advantage, as it allows the PO to communicate with the devs on the same level, and make informed contributions to the decision-making process.
• A

  What to do with a team that will never evolve into an agile one?
  agile team management scrum master communication agile coach • • amarantha  

  2
  0
  Votes
  2
  Posts
  0
  Views

  R

  As a Scrum Master, you can do your best. But your best might not be enough. I have seen people that were so distrusting and obviously hurt by their former bosses and management strategies of backstabbing, blaming and favoritism that they could not let go of those experiences and bring up the initial mental investment of extending a minimum of goodwill and trust to a new beginning. Teamwork is all about trust. "I need help" is a basic, fundamental sentence in team work. If you cannot find the courage to say it, because you have been experiencing for years or maybe even decades that this sentence only causes you pain from people that will exploit your weakness to it's fullest to gain something, then teamwork is impossible. I have had the fortune of witnessing this first hand. We had a big company with ~50 developers and we transitioned from command and control to multiple Scrum teams. Of the new formed teams, all under the same conditions, under the same Agile Coach and same line manager that did not interfere, some worked great, some just worked okay and some just didn't. Or only formally, but not as a real team. As a Scrum Master, you can educate and offer the opportunities for teamwork, but they have to be taken. You cannot force teamwork and trust on someone. If they don't put out a little bit of good will and see what happens if they are "weak" and ask for help but instead stay in their defensive shell, there is little you can do. You are a Scrum Master with a potential team member, not a psychologist with a patient. You can lead by example. You can offer opportunities. You cannot make people take them. And you certainly don't have the skillset to fix people's trust problems. As a step forward, if you find that your offered opportunities are not accepted, find out what the problem is. Do they not trust you? Then you need a different Scrum Master. Do they not trust each other? Then you need maybe a different team composition if you have multiple teams, or you need to replace those people that aren't trusted. Do they not trust the whole process, because they have been burned by the company before? Then there is little you can do. Make a list of opportunities you offered, explanations you gave, workshops you had, teamwork games you played, demonstrations to show that Scrum and teamwork produce better results. Go through it yourself and think about other opportunities. Talk to your team about it. If you cannot find a solution, talk to your manager about it. Scrum is not a silver bullet. It works through team work, it cannot enforce team work. If you find member(s) on your team to not be team players despite your best effort, you need to switch them out, as you would in any other team.
• 

  How do you as product owner decide that a product is feasible?
  product owner stakeholders • • emmalee  

  2
  0
  Votes
  2
  Posts
  0
  Views

  

  This is a really good question and one that doesn't get asked enough! Some things you can do to gain confidence in the feasibility of an idea: Build a business case for the idea (testing likely value versus likely cost) Build a prototype or a mock up that allows you to gauge customer response Build a https://en.wikipedia.org/wiki/Minimum_viable_product - something that is just functional enough for you to gain valuable feedback It is also important to run the idea by the development team to check the technical feasibility of the idea.