Sometimes, Agile isn’t the best choice, even if it is the most highly touted. Sometimes, it’s worth thinking critically about the project and its requirements to select a methodology that works better. In this post, I will explore a few of those Agile alternatives.
It can be rough to ask your development team to estimate work based on abstract story point values, especially when they are new to it or to each other. I know this and have experienced this in full.
So in this blog, I am going to share an exercise with you that will give every member of your team the same frame of reference for estimating the size of their work. I call this exercise Story Point Benchmarking.
With the recent news, many companies currently find themselves in the real situation of a sudden transition to a remote staff for the first time. With the snap of a finger, your team members suddenly lack the proximity to be able to function in the same exact way. Yet, work must be done and deadlines still need to be met.
In this blog, we introduce tips, suggestions, and takeaways for Agile software development team members to successfully work remotely or distributed for the first time.
Anyone who practices agile methodologies such as scrum is going to be very familiar with the practice of story pointing user stories (also known as poker planning). The good ole’ fashion 4, 8, 13, etc. Fibonacci sequences we assign to user stories of a sprint.
If you’re not familiar, it’s where the team gathers together to discuss the user stories to bring into a coming sprint and assigning each a number called story points. These story points are estimates that represent the level of difficulty and time it is expected to take to complete the story.
The team often will have discussions on whether a story is a particular story point number and argue their point of view until the team comes to an agreement to what story point it should be. I’ve done this type of work estimation for a long time that it’s natural for me… until we did something a bit different on a scrum team that I was a part of.
In this blog, we discuss a different way to assign poker points to user stories that could be beneficial to your scrum team – relative story sizing.
Imparting Knowledge And Preparing For The End Of A Contract
In this blog, I share an example of a consulting engagement that required significant knowledge transfer to new hires. We detail an approach for teaching Spring Batch to developers with no previous experience in Java or the Spring Framework.
The goal is to provide a real-world example of closing a contract, imparting knowledge with the client and their employees, and the potential issues faced in the process.
