Story points can mean different things to different people. Some see them as the effort needed to complete all related tasks, while others consider them a complexity measure. Since user stories focus on users' problems and needs, shouldn't we focus on the value these stories provide instead of the effort behind them? Users want solutions, not the details of our development process. That's why if we are already talking story points, we should instead address the value these stories bring to our users.
Imagine if we changed our planning poker sessions to focus on the value of each user story rather than its cost. It would still mostly be guessing, but many people agree that estimating is guessing anyway. Finally, it's not about the estimated number of points; the discussion within the team while estimating is the real benefit of the process, especially if we'd be discussing the value behind each story. It would be a significant change of perspective. Instead of pressuring the team to complete stories more quickly, we would unite to find the best ways to solve our users' problems.
I am on a team that works in a mob programming fashion, but we would very much like to be agile as well. What would be the best time to stop our session, get up, and do our Daily Standup?
An excellent resource about remote mob programming by INNOQ: https://www.remotemobprogramming.org.
Why is event sourcing still such a niche 'product'? Logging almost every possible technical information, ranging from debug messages to all kinds of exceptions, is generally accepted and a de facto standard. At the same time, discarding data and keeping only the current state is still the default approach in dealing with business case-related data.
When building a web UI for a product, the decision often comes down to which JS SPA framework to use. Another option might be worth considering if you already have a team skilled in Java (JVM) – based tech stack and frameworks like Spring and Spring Boot. Some of the mature (yes, you could also say boring) JAVA SSR frameworks like Apache Wicket and Vaadin or new options like HTMX might be just as good for the use cases you want to cover.
The alternatives might help you prevent unnecessary complexity, reduce your team's cognitive load, and prevent splitting the team into frontend and backend members while enabling every team member to focus on implementing user-related vertical slices of your product. Instead of introducing technical and infrastructure-related issues and challenges into your product delivery, you opt for a smaller team focused on building a valuable solution for your users.
Everybody likes a good story.
In the guide linked below about how to tell a story effectively, published by MasterClass (featuring instructors like Dan Brown and Salman Rushdie), one can find the following:
Choose a clear beginning and end to your story, then write the key plot events as bullet points between them.
That's why EventStorming and EventModeling are excellent and convenient tools for telling your product's story. Mix them with EventSourcing, and you can ensure the story is embedded into the product and remembered forever. Spread a layer of ExampleMapping on top, and let your product and its story live happily ever after.
MasterClass –> https://www.masterclass.com/articles/how-to-tell-a-story-effectively
A common practice of agile teams is estimating the cost or complexity of stories, quite often in collaborative planning poker sessions, while using story points as units. While this discussion and the shared understanding about the costs it hopefully leads to are essential, much more so than the actual story point number the team eventually comes up with, it would be such a pleasant surprise to see the whole product team discussing the actual value behind the stories planned similarly.
Having a shared understanding of the value of its work motivates the team. The discussion about the value itself is the positive side of the collaboration compared with the debate about the costs, which often, unfortunately, only leads to more stress and pressure on the development team. Finally, defining the value and costs of planned work items enables more meaningful prioritization. Using the language of the Agile Manifesto itself, one could express the above approach as “Value exploration over cost estimation.”
One of the benefits of the EventModeling approach is that spatially laying out the system as a sequence of state changes and dividing it into vertical, user-centric slices implicitly follows the above principle. A slice, as such, is already a vertical, user-centric, sufficiently specified unit of work and has a cost of one slice. The team can now focus on identifying and building the most valuable slices first.
For more details about EventModeling, visit https://eventmodeling.org.
I reread Shape Up again. Since I am impressed with the Event Modeling approach and have been playing with it quite a lot recently, I wonder whether the two could indeed be a match made in heaven when it comes to developing software. Shaping work for six weeks with Event Modeling sounds like a pretty good idea. Event Modeling helps during Shaping, while Breadboarding helps define the UI for the Event Model.
Consider the practical application of this approach in building, let's say, a virtual reality platform. Imagine splitting the flow into six equal-length slices, each representing a significant step towards the successful genesis of your own virtual world. Events like SkyCreated, LightCreated, or SeasCreated could be assigned to one slice each, culminating in Shape Up's cool-off phase as the seventh slice, where you can rest from all the hard work.
Usually, when following the Shape Up approach, you would be working in small teams of two (three at most), one designer and one developer, but let's say you are alone in your endeavor and are a truly intelligent designer with impressive building skills as well. You might even manage the initial creation of the platform on your own. Before you start, though, you might consider the operations of your platform afterward and how much effort it requires. The “You built it, you run it” approach might be exhausting in the long run, even if you are pretty convinced of your abilities. If, at some point later on, you do reach a point where you feel like there is no meaningful way forward, and the only option you are left with is to take the platform down, make sure to do it properly. You don't want to leave it running in the background as a daemon process.
p.s. Both of these are very much worth looking into :
https://basecamp.com/shapeup
https://eventmodeling.org
In my previous life, I was the founder and managing director of a pretty successful company for almost two decades. One afternoon, working in our office, I noticed some colleagues leaving the man‘s room with a befuddled state of mind while gliding smoothly and greasily away. After a while, I decided to check what was going on and found out that there was no toilet paper left. I immediately went to the nearest store and bought some. Achievements like these were what kept me going all those years. So, if in doubt about how to best support your team, stop all that very important managing and strategizing and instead go out and buy some toilet paper. Because shit happens. One way or the other.
What I find incredibly motivating is that there is a person on my team who comes into our office every day at the same time whom we call master, gets me to stand up each time we meet, and requests information about what I have done since the time he was here the day before and what I intend to do until his next visit tomorrow. Everybody on my team also seems highly motivated since each of us takes a dedicated story immediately and tries to implement it as fast as possible. Sometimes, I skip writing tests to be even faster. Frankly, I would skip a compiler if I could to save even more time. That‘s how motivated I am. The only interruptions I tolerate when working are when my master creates and assigns a new user story to me in our ticketing system and pings me to fill the story points based estimation accordingly. As a developer, I want to scream with joy infused by all the positive energy so that everybody working in our office building can get energized, too.
I think that Scrum Master is a regrettable name for the role. It sounds like a management role with a significant level of authority already. Maybe that’s one of the reasons why it often attracts the wrong mindset. Scrum Butler might have been a better name, considering what the role is supposed to be about. But what would the rate of Scrum adoption be then? How valuable would a Certified Scrum Butler title be for someone’s career? How many training sessions and exams could one sell? And does an organization with a servant mindset among its management already need a framework like Scrum? At least for the organizations out there performing daily agile theatre, it could be of some benefit, though. Those skeptical voices about how Agile is dead will get louder, eventually looking for someone to blame for the disaster. Identifying who killed Agile at their organization wouldn’t require a lengthy investigation. It was the butler, obviously.