In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.
Following are the some of the reasons why sprint success is important.
Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.
Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.
Fig: Habit Loop
Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.
High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.
Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes bigger than individuals and deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.
These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.
I have repeatedly heard from teams that we have done estimation for stories in terms of story points or t-shirt sizes hence now why do we create tasks or if at all if we create tasks why do we add hours to tasks? Add to that what is the need for specifying actual vs remaining hours every day for each task. The story is good enough to know what is to be done so why look at tasks. The benefits over challenges are much bigger and you can be truly convinced when you attempt it.
The recommendation is to have tasks created for each story. Typically individual task should not be more than a day. If that’s the case, break it down further. Almost every task can be practically broken down to meet this criteria. Once tasks are created, each task should be tagged to approx. hours needed for the same.
While creating tasks not just restrict yourselves to functional requirements while focus on following but not limited to
Non Functional Requirements (Performance, Security, Scalability, compliance, accessibility, maintainability etc. )
The best time to create task is pre-grooming which is done few days ago before actual sprint planning/grooming. It is my personal recommendation to get as many tasks as possible before you go for actual grooming. You can always convince team how you have come up with these tasks.
I am listing some of the core benefits of creating tasks, assign hours to each tasks during planning, smaller tasks and further constantly entering actual hours and hours remaining
The tasks add lots of clarity to story. I always advice individuals to create tasks before actual planning meeting. The pre-grooming done in advance in earlier sprint is when tasks should be created. This results in better estimation further result in better planning.
It is always simple to do individual smaller tasks over doing entire story. It is undoubtedly faster better and cheaper option.
Having tasks for individual story make it very easy to share your story work with other team members.
The hour assignment for each tasks helps in predictability of complete the tasks. The risks can be mitigated much earlier or in many cases it can be avoided during planning itself.
The actual vs remaining helps to come up with burndown chart which is one of the core artifact of agile teams. You can always have burndown based on # of items closed or velocity burned but that doesn’t give clarity and adds up little or no value.
Adds lot of value to individual accountability as it gives clear picture in terms of who is doing what and whether he/she is taking longer or getting it done early. This is one of the main cause many agile members are not inclined to go and add that much of details. The thinking of to become accountable is not a good idea is in reality bad for developers. More than an organization loss, they are killing their careers.
Small victories (after completing each tasks) gives motivation to individuals.
You are directly or indirectly reducing assumption on stories resulting success chances getting better. “Assumption is mother of all screw ups”. You can’t run away with assumptions while reducing the numbers helps you to do more.
The question which you might ask your stakeholders at later stage is typically unearthed well in advance.
In majority of cases better sprint success rate by having tasks and further hours (Planned, actual and remaining)
The nonfunctional requirements (security, performance, scalability etc) are listed in advance and these are being considered while planning
These NFRs, code reviews, testing etc are never missed. Typically POs encourages to list only requirements those have business values while I always recommend to write all the tasks which you are going to do.
The dependencies, constraints are identified. Moreover the acceptance criteria is well covered. The tasks suffice the need for missing SRS (Software Requirement Specifications) in agile projects.
The productivity is bound to be better in addition to quality. I have personally worked with tons of teams and experience the same.
Better bonding within team as things are BETTER organized.
You can better calculate matrices like productivity, cycle time, utilization etc.
Estimations in scrum/agile environments often gets tangled in conversations about how big of an effort that is required. The questions that are often asked are “how much of effort?”, “how long/sprints it will take?”, “Is it too complex?”
Scrum provides a model where these questions are easily compressed to a simple thing called story points. Story points is a number denoting the complexity/effort/time taken by the team to solve a problem (story). Story points are often a number of Fibonacci series. (1, 2, 3, 5, 8, 13 …). The scrum team defines what it means by a 1 pointer story. For example one of our teams defined a 1 pointer as “one line of code change”. Also as the number of unknowns in a story is high, team provide higher story points for the story.
However the size of the story points is not important because
Story point size is specific to the team and can not be used to compare teams. A story could be sized differently by different teams based on the understanding of the product, technology and experience.
When a management provides a commitment on a given epic/release to the customer, the delivery timeline is often determined by the velocity and not by individual story sizes.
Story points are a relative sizing of the stories and not a exact reflection of complexity/effort
Bigger story points does not mean higher customer value. A refactoring story or a story of lower business impact could be sized bigger.
Story points are time bound. The team could size the story differently depending on their understanding, as their knowledge/understanding changes their story sizes also change. This is one of the reasons some teams re-look at the story sizes during sprint planning although they are sized.
Please let us know your thoughts, using story points? does size matter?
In a typical agile environment, as there is no specific design phase, and there are often questions about when the design and architecture happens. There is continuous evolution of architecture and design that happens during the sprint and iterations. Also the conventional roles like Managers and Architects have no room in an agile environment. In this article we will discuss who do we call an Architect in an agile environment and what are their characteristics.
An agile architect is a developer working and taking the most important technical decisions on the product. This is generally a person who has deep knowledge of the product and the technologies used and have great ownership in taking it to the next level. This definition beats the conventional definitions of a software architect who generally creates artifacts (like class diagram, sequence diagram etc) to be consumed by developers. An agile architect also do these conventional things in order to empower other developers, but also leads & helps the team to solve daily problems faced to implement the technical direction.
Be Agile: Agile architects are highly flexible and adaptable to changing requirements and environments and always open to changes.
Right tool for the problem : Agile architects often have good knowledge on more than one development language and are always open to newer technologies and solutions. When they are solving an intense problem, they use the right tool to solve that.
Emergent Design: Agile architects know that we can not fix the architecture at one go while the requirements keeps changing. So they are always ready to change the architecture and design based on the current business requirements.
Always Learning: They know there is always a better way to do thing and are open to do changes to their current tools, techniques and processes.
Refactor it in free time: When code does not reach perfection, they are open to achieve the business results and then do code refactoring to fix the flaws.
TDD/BDD: Agile architects always follow best practices like TDD/BDD so that the code is always nimble to new architectural changes.
Team along: As architecture and design is in the hands of every developer, agile architects always bring the team along and continuously get their inputs and provide technical directions.
Respect: There is no ivory tower for an agile architect, they are always part of the team and delivering results. So they respect other team members opinions and ideas and focus on delivering the best results for the product.
In this ever changing business environment, developers are often asked to deliver more and more in less time. Agile architects are a big asset to a team in providing technical, architectural and design guidance to the team.
Product Owner (PO) – PO is a key stakeholder in an Agile project. He/She is responsible for defining or detailing the vision, understanding organization goals and ensure to align project goals with it.
Defines the features and stories of the product. Responsible for elaborating requirements, clarify doubts and clearly stating acceptance criteria.
Review and accept/reject the work accomplished by the team.
Responsible for prioritization of the work.
Responsible for release planning.
Owns product backlog and release backlog.
Remove functional impediments and constantly answer product related questions to the team.
Constantly talking to other POs to align product/project changes with business unit/organization goals.
Responsible for the return of investments.
Constantly working with the customer to fulfill their needs and better understand their requirements.
This is management function of Scrum.
Facilitate the daily standups.
Setting up retrospectives, pre-grooming, showcase and other meetings.
Remove impediments or obstacles for all kinds (technical, functional, resource etc.)
Co-ordinate with POs, Team, Manager and all the project holders.
Ensure team productivity and closely working with them to ensure quality requirements are enforced.
Ensure team understands the processes and adhere to them.
Protect team from external interferences and interruptions.
Responsible for actual implementation.
Owns Sprint Backlog while the priority of Sprint backlog should be derived from the product backlog.
The recommended size is between 6 to 10 people. The best practice is to have 7 member team.
All the members are expected to be full-time. The exceptions could be DBA or some specialized skill needed on a temporary basis.
Proactively identify ways and opportunities to improve the performance of the team and constantly get better.
Are set of programmers, DBAs, tech writers, technical experts, domain experts, independent testers etc.
Must be self-organizing.
Constantly communicate with the team and ensure to meet sprint goals.
To share all information in daily standups including “work in progress”
To support each other. Most importantly consider sprint goal a priority over individual goals.
Avoid accepting outside or extra work without consent from team.in
Agile software development or methodology or framework refers to time boxed, continuous iteration of development and testing to build software where the solutions evolve throughout with incremental development via collaboration among self-organizing teams. Agile helps organizations to expertise and respond to continuous change and make them able to do more.
As shown in above diagram, the vision and feasibility are most important factors to be considered before starting a project. In this phase, we identify whether we should consider doing a project or not. Some of the questions need to be answered in this phase like what is going to be ROI (Return of investments) for a project? How do we get funding? Is it worth taking risks? Staffing? what is the value the project bring in? etc. You use this phase to break the idea into individual functionality items called features or user stories. If this looks positive, the next step is to create a product roadmap document.
The product backlog is created leveraging the product roadmap document. The release planning results in release backlog. The individual sprints are defined to accomplish upcoming release goals. The Agile Roadmap blog defines the entire project in more details.
One of the powerful retrospective getting very popular lately is Sad/Mad and Glad. Many organizations don’t even conduct it as they are afraid to talk about employee challenges or too busy to do other things that they don’t have time to focus on employee morale. There are obviously pros and cons but making it work truly helps you to achieve more. In my personal opinion, the number of positives what you have with this retrospective is far higher than challenges hence it’s worth doing it.
Your team and your presence
Sticky notes (Three colors)
Open minded motivated teams
In this retrospective, you ask your team to get into a room. Every colored sticky note represents Sad/Mad or Glad respectively. You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!
You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!
You can start your meeting with a positive note. Ask individuals to participate freely and openly. Once the stage is all set, you can ask every individual to write up the areas what they are happy about it (Glad), don’t like it (Sad) or frustrated with it (Mad) on different color sticky notes. I always recommend individual team members to write their names on each sticky note else there are good chances that it would become a political battle.
I have seen instances where team members just write some crap either because they did not have good appraisal last time or not in line with others due to personal issues. If you find an item which has something written in sad or mad while an individual who wrote it is not willing to even talk about it then you can very much assume either that’s fake or written with the wrong intention. There are some people very shy and not willing to open at all. They should go to their manager or who is driving sad mad/glad to discuss the area of concern. Just to avoid the frustration as manager, anything written as an area of concern and individual is not willing to open up personally or with the team, you can safely scrap it.
Once everyone is done with writing, spend an hour or so reading every item and discuss that with the team. Remember the goal is to share as much as information about the issue and gaining more details around the problem while not fixing the problem there itself. This would be good input to take it forward as employee happiness and moral is very critical to agile success.
Things to remember while doing Sad/Mad & Glad:-
You should be reading every item loud or make it visible to every individual unless there is a derogatory remark which is not acceptable.
Team to think of the success of team and project rather considering this as revenge material.
Everyone must open up. If you don’t have guts to talk about your challenge then don’t even write it. You are just creating a FUSS which is either not true or you don’t know what is this the right forum to talk about it.
Refrain from making comments about an individual if you don’t have supporting material. The world is not perfect. The goal is to identify the improve system over making it worse
Should not be anonymous.
Don’t abuse it. It is conducted to the best interest of an individual and improves as a team. It should never be used as a tool to fulfill your political battle.
Not every problem can be fixed eventually. Somebody writes that I don’t feel like working doesn’t mean you would allow him to sleep in the office.
Don’t try to fix the problems during this retrospective.
Constantly read the issues/concerns raised and strive to fix as much as you can. Provide updates to the team around the issues you committed you would work on.
The benefits I see with this retrospective are:-
Gives lots of motivation to the team when going over “Glad” items.
Give an opportunity to an employee to express their challenges.
Bring in open culture
Reduce attrition as you really know challenges and definitely a lot of which you can work on.
It gives 360 views in terms of how the teams are progressing.
One of the biggest “Glad” item I would say is that your organization is conducting it.
The challenges I see are:-
It may become a political battle if your team is not mature and willing to go for an anonymous survey.
Excessive sad mad and glad would unearth issues which are not really problems while making other team members think it’s a major problem.
Sometimes very happy team morale goes down as well as when you have an opportunity to think about negatives, you feel like writing it and further “law of attraction” does its job.
What I was written must be addressed and fixed “Myth”. You may not like the tile color in the washroom but that cannot be really changed.