During the lockdown, we do Planning Poker in Zoom or Teams. Which tool can you use the best to collaboratively determine our estimates? Which facilitates the best interaction in your Scrum team?
Why you should you keep doing Planning Poker?
You’d like to keep doing this, because this Refinement practice naturally raises:
1. The team’s awareness of what work is expected and get clarification. 2. Knowledge and tactics will be shared 3. Assumptions will become clear 4. Negotiation with the Product Owner will occur to keep it small AND valuable
Which Planning Poker tool to use online in Zoom? or Teams?
What’s the best Planning Poker tool would you use in Zoom or Teams? I had a discussion with my Agile coach colleagues within Xebia. We agree analog cards trumps any online tool. Why?
A. First, analog cards are easily made available to anyone. So, no firewall to jump over. And no licenses needed. No security compliance issue. Just create them!
B. Secondly, each team member could create the card deck themselves. As a consequence this fosters ownership. Some will introduce some fun and/or improvement. Especially, if you encourage any team member, to introduce an extra card. For example, ‘time for a break’ or ‘we try to estimate too soon’.
C. Most importantly, it will naturally enforces any team member to put the camera on. Raising opportunities to spot non-verbal signals of anyone. That’s great!
This together comes close to mirror the office situation. And as an advantage, the screen sharer doesn’t need to switch applications all the time.
See my deck of cards. Easily made of some thick paper and a fat black marker, for instance.
You can use these planning Poker cards in any Zoom or Teams meeting. A low-tech solution facilitating great interaction!
Any questions? Raise them below!
Your potential next step to increase your effectiveness in Scrum:
Would you like to deepen your tactics in great Refinement? Join classes like Specification by example by Gojko Adzic It is the cornerstone of any successful requirements and testing strategy with Agile and Lean processes, like Scrum, Extreme Programming, and Kanban. This workshop teaches you how to apply SBE to bridge the communication gap between stakeholders and implementation teams, build quality into software from the start, design, develop, and deliver systems fit for purpose.
Make your team stronger. Distribute the workload of testers among time better and become better as a team? Understanding cross functional competences and needs will increase while applying Test Driven Development.
In essence, personas help teams understand if the designed functionality actually fits the end-user desires. This makes it a powerful approach to also identify possible risks by introducing malicious users or ‘evil personas’.
Security is about making risks visible and mitigating the impact of possible incidents to an acceptable level. The ‘security by design’ philosophy aims for every application or system to be at an acceptable risk level, all the time.
When starting with a ‘secure by design’ approach, often existing security processes are simply bolted onto the development life-cycle. One of the major pitfalls of this approach is requiring teams to do a YAPWAV. YAPWAV stand for the developer’s hell called: Yet Another Process Without Added Value. A YAPWAV is an activity a team solely has to do to please a stakeholder, without noticeably improving the product they’re building.
A classic example of a YAPWAV is the mandatory risk assessment for each software deployment, just for the purpose of satisfying a documentation process. These kinds of security processes are bound to fail as they add no (visible) value to the product the team is building. In the agile philosophy, every action or activity should contribute to the value of the product. The moment an activity is introduced that doesn’t add visible value, teams will decide it’s not worth the effort and stop doing it.
Welcome to my second blog in the series of five quality patterns in Agile development that can help you to deliver the right software with great quality. In my previous blog, I’ve introduced Example Mapping as a method to get to specific examples for scenarios or rules that your user story is made up of. The output of the refinement sessions are your requirements and thus your tests. In this blog, we will take a further look at these test cases and why it is important to automate these acceptance tests. Not just from a development team perspective, but also what they can bring to your business.
Are you worried your new project won’t be successful? Or afraid getting stuck applying these new techniques you just learned in a training? Or are you perhaps part of a very pro-active organization, but is a lack of focus crushing all new initiatives in the long run?
At Xebia we help customers as consultants, but also as facilitators or as trainers. A common pattern we see is people worry about how to move forward with their newly acquired knowledge or insights. In order to improve your chances of success, it can be very useful to do an upfront analysis of the causes of these worries. This will help you steer clear of the rocks, and prevent early ship wreckage of your new ideas. One of the formats we’ve been using over the years is the so-called Pre-mortem.
There are several recurring wishes our clients bring to us, one of which is speed, to improve time to market. However, there is no dial that we can turn to deliver value faster. Software teams are not like cars; there’s no accelerator pedal. Even if we try to speed up by adding more resources, in many cases, the actual bottleneck will just become more apparent.
In our search for increased delivery of value, we hunt for these bottlenecks. No two contexts are the same, and for this story, we have a particular context in mind. Symptoms in different organizations are often similar, and our story might apply to your setting if you recognize the problems we encountered.
As Scrum Trainer I get to meet a lot of teams and hear of many different ways to do Scrum. Most are valid ways, yet some seem more aligned with the values of Scrum or the purpose of the specific Scrum Element. In this post we’ll have a look at the Sprint Review.
The Sprint Review is generally the hardest event to get right. It’s where the Scrum Team and their stakeholders meet, thus the event with the largest number of participants. It’s also the event in which different people come with a different purpose.
The Development Team is present to show their work and receive feedback. They’re hopefully also there to connect to their stakeholders.
The Product Owner is also there for the feedback, but also to verify the longer term road-map and the state of the product backlog.
The Stakeholders often come to see the things they requested. We also ask them to share insights they have gathered during the sprint and to collaborate on the Product Backlog.
One thing I’ve observed is that the focus is often on What was planned and What is now “Done”. I feel this is an anti-pattern. While progress is important, I feel the focus should be on What is “Done” and What to do next.
Multi Products Scrum teams are in reality observed often. One team serving different stakeholders and customer segments. Both would like to use the same people to work on their improvements.
In most organizations there tend to be more products than teams. While scaling frameworks give solutions on how to cope with a big Product and orchestrating value delivery among multiple teams. But how to deal with many products and a few Scrum teams?
In this blog series, I’ll discuss five quality patterns in Agile development to deliver the right software with great quality.
For years now companies have been adopting Agile ways of working and mostly the Scrum framework as their way to develop software. Scrum is all about working in dedicated teams on small increments of working software. Software that can potentially be released every single sprint. I’m sure you agree with me that this means that this software is therefore always tested every sprint as well. How could we otherwise release it right? This blog is about a trend I have noticed in a lot of companies that after time teams have more and more issues delivering quality software that conforms to business requirements.